Techniques for Security Key Generation by User Devices for Data Transmission in an Inactive State

ABSTRACT

An example technique for security key derivation in a wireless system includes: receiving a radio resource control (RRC) suspend message from a first node, the RRC suspend message including a first next hop (NH) chaining counter (NCC) value, entering a RRC inactive state, deriving a first node key based on the first NCC value, generating a first uplink message for transmission in the RRC inactive state based on the first node key, and transmitting the first uplink message to a node while in the RRC inactive state.

FIELD

The present application relates to wireless devices, includingapparatus, systems, and methods for generating security keys by userdevices for use in data transmissions to a node while the user device isin an inactive state.

BACKGROUND

Wireless communication systems are rapidly growing in usage. In recentyears, wireless devices such as smart phones and tablet computers havebecome increasingly sophisticated. In addition to supporting telephonecalls, many mobile devices now provide access to the internet, email,text messaging, and navigation using the global positioning system(GPS), and are capable of operating sophisticated applications thatutilize these functionalities. Additionally, there exist numerousdifferent wireless communication technologies and standards. Someexamples of wireless communication standards include GSM, UMTS(associated with, for example, WCDMA or TD-SCDMA air interfaces), LTE,LTE Advanced (LTE-A), HSPA, 3GPP2 CDMA2000 (e.g., 1×RTT, 1×EV-DO, HRPD,eHRPD), IEEE 802.11 (WLAN or Wi-Fi), BLUETOOTH™, etc.

The ever increasing number of features and functionality introduced inwireless communication devices also creates a continuous need forimprovement in both wireless communications and in wirelesscommunication devices. To increase coverage and better serve theincreasing demand and range of envisioned uses of wirelesscommunication, in addition to the communication standards mentionedabove, there are further wireless communication technologies underdevelopment, including fifth generation (5G) new radio (NR)communication. Accordingly, improvements in the field in support of suchdevelopment and design are desired.

SUMMARY

Aspects of the present disclosure relate to apparatuses, systems, andmethods for security key derivation for use by user devices to securetransmissions to a node, while the user device is in an inactive state.

In certain wireless systems, data as between a user device and a centralnetwork (CN) may be independently ciphered and/or integrity protected asbetween the UE and a particular node. These independent layers ofciphers and/or integrity protection help allow for data security andprivacy. In certain cases, a UE may enter a radio resource control (RRC)inactive state, whereby a non-access stratum (NAS) connection to a CN ismaintained, but access stratum (AS) resources are released. There is aneed to allow user devices to transmit data while remaining in the RRCinactive state. As the AS resources are released, there is a need todefine ways to determine a ciphering or integrity protection key for usewhen the user device transmits UL data while remaining in the inactivestate.

Thus, according to some aspects disclosed herein, a method for securitykey derivation in a wireless system, comprising: receiving a radioresource control (RRC) suspend message from a first node, the RRCsuspend message including a first next hop (NH) chaining counter (NCC)value; entering a RRC inactive state; deriving a first node key based onthe first NCC value; generating a first uplink message for transmissionin the RRC inactive state based on the first node key; and transmittingthe first uplink message to a node while in the RRC inactive state.

In some aspects, the method may further comprise cases wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein the first node key is the same as thesecond node key. In some aspects, the method may further comprise caseswherein the first NCC value is different from a second NCC valuepreviously used to derive a second node key. In some aspects, the methodmay further comprise receiving first cell information from the firstnode, wherein the first node key is derived based on the first NCC valueand the first cell information from the first node; generating a seconduplink message for transmission in the RRC inactive state based on thefirst node key; and transmitting the second uplink message while in theRRC inactive state. In some aspects, the method may further comprisehorizontally deriving a third node key based on the first node keygenerating a third uplink message for transmission in the RRC inactivestate based on the third node key; and transmitting the third uplinkmessage to the third node while in the RRC inactive state. In someaspects, the method may further comprise cases wherein the RRC suspendmessage includes multiple NCC values and further comprising: verticallyderiving a second node key based on a second NCC value of the multipleNCC values; generating a second uplink message for transmission in theRRC inactive state based on the second node key; and transmitting thesecond uplink message to a node while in the RRC inactive state. In someaspects, the method may further comprise cases wherein the first uplinkmessage is transmitted to a second node and further comprising:receiving a second NCC value from the second node; vertically deriving asecond node key based on the second NCC value; generating a seconduplink message for transmission in the RRC inactive state based on thesecond node key; and transmitting the second uplink message while in theRRC inactive state to a third node

The techniques described herein may be implemented in and/or used with anumber of different types of devices, including but not limited tocellular phones, wireless devices, tablet computers, wearable computingdevices, portable media players, and any of various other computingdevices.

This Summary is intended to provide a brief overview of some of thesubject matter described in this document. Accordingly, it will beappreciated that the above-described features are merely examples andshould not be construed to narrow the scope or spirit of the subjectmatter described herein in any way. Other features, aspects, andadvantages of the subject matter described herein will become apparentfrom the following Detailed Description, Figures, and Claims.

BRIEF DESCRIPTION OF DRAWINGS

A better understanding of the present subject matter can be obtainedwhen the following detailed description of various aspects is consideredin conjunction with the following drawings, in which:

FIG. 1 illustrates an example wireless communication system, inaccordance with aspects of the present disclosure.

FIG. 2 illustrates a base station (BS) in communication with a userequipment (UE) device, in accordance with aspects of the presentdisclosure.

FIG. 3 illustrates an example block diagram of a UE, in accordance withaspects of the present disclosure.

FIG. 4 illustrates an example block diagram of a BS, in accordance withaspects of the present disclosure.

FIG. 5 illustrates an example block diagram of cellular communicationcircuitry, in accordance with aspects of the present disclosure.

FIG. 6 illustrates an example block diagram of a network element, inaccordance with aspects of the present disclosure.

FIGS. 7-8 are communications flow diagrams illustrating communicationsflows for entering and resuming from an RRC inactive state, inaccordance with aspects of the present disclosure.

FIG. 9 is a diagram illustrating key derivation, in accordance withaspects of the present disclosure.

FIGS. 10-20 are communications flow diagrams illustrating exampletechniques for key generation for inactive state data transmissions, inaccordance with aspects of the present disclosure.

FIG. 21 is a flow diagram illustrating a technique for key generation bya user device for inactive state data transmissions, in accordance withaspects of the present disclosure.

FIG. 22 is a flow diagram illustrating a technique for generatingadditional keys by the user device for inactive state datatransmissions, in accordance with aspects of the present disclosure.

FIG. 23 is a flow diagram illustrating a technique for generatingadditional keys by the user device for inactive state datatransmissions, in accordance with aspects of the present disclosure.

FIG. 24 is a flow diagram illustrating a technique for key generation bya node for inactive state data transmissions, in accordance with aspectsof the present disclosure.

FIG. 25 is a flow diagram illustrating a technique for generatingadditional keys by node for inactive state data transmissions, inaccordance with aspects of the present disclosure.

FIG. 26 is a flow diagram illustrating a technique for generatingadditional keys by node for inactive state data transmissions, inaccordance with aspects of the present disclosure.

While the features described herein may be susceptible to variousmodifications and alternative forms, specific aspects thereof are shownby way of example in the drawings and are herein described in detail. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to be limiting to the particularform disclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the subject matter as defined by the appended claims.

DETAILED DESCRIPTION

The following is a glossary of terms that may be used in thisdisclosure:

Memory Medium—Any of various types of non-transitory memory devices orstorage devices. The term “memory medium” is intended to include aninstallation medium, e.g., a CD-ROM, floppy disks, or tape device; acomputer system memory or random access memory such as DRAM, DDR RAM,SRAM, EDO RAM, Rambus RAM, etc.; a non-volatile memory such as a Flash,magnetic media, e.g., a hard drive, or optical storage; registers, orother similar types of memory elements, etc. The memory medium mayinclude other types of non-transitory memory as well or combinationsthereof. In addition, the memory medium may be located in a firstcomputer system in which the programs are executed, or may be located ina second different computer system which connects to the first computersystem over a network, such as the Internet. In the latter instance, thesecond computer system may provide program instructions to the firstcomputer for execution. The term “memory medium” may include two or morememory mediums which may reside in different locations, e.g., indifferent computer systems that are connected over a network. The memorymedium may store program instructions (e.g., embodied as computerprograms) that may be executed by one or more processors.

Carrier Medium—a memory medium as described above, as well as a physicaltransmission medium, such as a bus, network, and/or other physicaltransmission medium that conveys signals such as electrical,electromagnetic, or digital signals.

Programmable Hardware Element—includes various hardware devicescomprising multiple programmable function blocks connected via aprogrammable interconnect. Examples include FPGAs (Field ProgrammableGate Arrays), PLDs (Programmable Logic Devices), FPOAs (FieldProgrammable Object Arrays), and CPLDs (Complex PLDs). The programmablefunction blocks may range from fine grained (combinatorial logic or lookup tables) to coarse grained (arithmetic logic units or processorcores). A programmable hardware element may also be referred to as“reconfigurable logic.”

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, Internet appliance, personal digitalassistant (PDA), television system, grid computing system, or otherdevice or combinations of devices. In general, the term “computersystem” can be broadly defined to encompass any device (or combinationof devices) having at least one processor that executes instructionsfrom a memory medium.

User Equipment (UE) (or “UE Device”)—any of various types of computersystems or devices that are mobile or portable and that perform wirelesscommunications. Examples of UE devices include mobile telephones orsmart phones (e.g., iPhone™, Android™-based phones), portable gamingdevices (e.g., Nintendo DS™, PlayStation Portable™, Gameboy Advance™,iPhone™), laptops, wearable devices (e.g., smart watch, smart glasses),PDAs, portable Internet devices, music players, data storage devices, orother handheld devices, etc. In general, the term “UE” or “UE device”can be broadly defined to encompass any electronic, computing, and/ortelecommunications device (or combination of devices) which is easilytransported by a user and capable of wireless communication.

Wireless Device—any of various types of computer systems or devices thatperform wireless communications. A wireless device can be portable (ormobile) or may be stationary or fixed at a certain location. A UE is anexample of a wireless device.

Communication Device—any of various types of computer systems or devicesthat perform communications, where the communications can be wired orwireless. A communication device can be portable (or mobile) or may bestationary or fixed at a certain location. A wireless device is anexample of a communication device. A UE is another example of acommunication device.

Base Station—The term “Base Station” has the full breadth of itsordinary meaning, and at least includes a wireless communication stationinstalled at a fixed location and used to communicate as part of awireless telephone system or radio system. For example, if the basestation is implemented in the context of LTE, it may alternately bereferred to as an ‘eNodeB’ or ‘eNB’. If the base station is implementedin the context of 5G NR, it may alternately be referred to as a ‘gNodeB’or ‘gNB’. Although certain aspects are described in the context of LTEor 5G NR, references to “eNB,” “gNB,” “nodeB,” “base station,” “NB.”etc., may refer to one or more wireless nodes that service a cell toprovide a wireless connection between user devices and a wider networkgenerally and that the concepts discussed are not limited to anyparticular wireless technology. Although certain aspects are describedin the context of LTE or 5G NR, references to “eNB,” “gNB,” “nodeB,”“base station,” “NB,” etc., are not intended to limit the conceptsdiscussed herein to any particular wireless technology and the conceptsdiscussed may be applied in any wireless system.

Node—The term “node,” as used herein, may refer to one more apparatusassociated with a cell that provide a wireless connection between userdevices and a wider network generally.

Processing Element (or Processor)—refers to various elements orcombinations of elements that are capable of performing a function in adevice, such as a user equipment or a cellular network device.Processing elements may include, for example; processors and associatedmemory, portions or circuits of individual processor cores, entireprocessor cores, individual processors, processor arrays, circuits suchas an ASIC (Application Specific Integrated Circuit), programmablehardware elements such as a field programmable gate array (FPGA), aswell any of various combinations of the above.

Channel—a medium used to convey information from a sender (transmitter)to a receiver. It should be noted that since characteristics of the term“channel” may differ according to different wireless protocols, the term“channel” as used herein may be considered as being used in a mannerthat is consistent with the standard of the type of device withreference to which the term is used. In some standards, channel widthsmay be variable (e.g., depending on device capability, band conditions,etc.). For example, LTE may support scalable channel bandwidths from 1.4MHz to 20 MHz. In contrast, WLAN channels may be 22 MHz wide whileBluetooth channels may be 1 Mhz wide. Other protocols and standards mayinclude different definitions of channels. Furthermore, some standardsmay define and use multiple types of channels, e.g., different channelsfor uplink or downlink and/or different channels for different uses suchas data, control information, etc.

Band—The term “band” has the full breadth of its ordinary meaning, andat least includes a section of spectrum (e.g., radio frequency spectrum)in which channels are used or set aside for the same purpose.

Automatically—refers to an action or operation performed by a computersystem (e.g., software executed by the computer system) or device (e.g.,circuitry, programmable hardware elements, ASICs, etc.), without userinput directly specifying or performing the action or operation. Thusthe term “automatically” is in contrast to an operation being manuallyperformed or specified by the user, where the user provides input todirectly perform the operation. An automatic procedure may be initiatedby input provided by the user, but the subsequent actions that areperformed “automatically” are not specified by the user, i.e., are notperformed “manually”, where the user specifies each action to perform.For example, a user filling out an electronic form by selecting eachfield and providing input specifying information (e.g., by typinginformation, selecting check boxes, radio selections, etc.) is fillingout the form manually, even though the computer system must update theform in response to the user actions. The form may be automaticallyfilled out by the computer system where the computer system (e.g.,software executing on the computer system) analyzes the fields of theform and fills in the form without any user input specifying the answersto the fields. As indicated above, the user may invoke the automaticfilling of the form, but is not involved in the actual filling of theform (e.g., the user is not manually specifying answers to fields butrather they are being automatically completed). The presentspecification provides various examples of operations beingautomatically performed in response to actions the user has taken.

Approximately—refers to a value that is almost correct or exact. Forexample, approximately may refer to a value that is within 1 to 10percent of the exact (or desired) value. It should be noted, however,that the actual threshold value (or tolerance) may be applicationdependent. For example, in some aspects, “approximately” may mean within0.1% of some specified or desired value, while in various other aspects,the threshold may be, for example, 2%, 3%, 5%, and so forth, as desiredor as required by the particular application.

Concurrent—refers to parallel execution or performance, where tasks,processes, or programs are performed in an at least partiallyoverlapping manner. For example, concurrency may be implemented using“strong” or strict parallelism, where tasks are performed (at leastpartially) in parallel on respective computational elements, or using“weak parallelism”, where the tasks are performed in an interleavedmanner, e.g., by time multiplexing of execution threads.

Configured to—Various components may be described as “configured to”perform a task or tasks. In such contexts, “configured to” is a broadrecitation generally meaning “having structure that” performs the taskor tasks during operation. As such, the component can be configured toperform the task even when the component is not currently performingthat task (e.g., a set of electrical conductors may be configured toelectrically connect a module to another module, even when the twomodules are not connected). In some contexts, “configured to” may be abroad recitation of structure generally meaning “having circuitry that”performs the task or tasks during operation. As such, the component canbe configured to perform the task even when the component is notcurrently on. In general, the circuitry that forms the structurecorresponding to “configured to” may include hardware circuits.

Various components may be described as performing a task or tasks, forconvenience in the description. Such descriptions should be interpretedas including the phrase “configured to.” Reciting a component that isconfigured to perform one or more tasks is expressly intended not toinvoke 35 U.S.C. § 112(f) interpretation for that component.

Example Wireless Communication System

Turning now to FIG. 1 , a simplified example of a wireless communicationsystem is illustrated, according to some aspects. It is noted that thesystem of FIG. 1 is merely one example of a possible system, and thatfeatures of this disclosure may be implemented in any of varioussystems, as desired.

As shown, the example wireless communication system includes a basestation 102A, which communicates over a transmission medium with one ormore user devices 106A, 106B, etc., through 106N. Each of the userdevices may be referred to herein as a “user equipment” (UE). Thus, theuser devices 106 are referred to as UEs or UE devices.

The base station (BS) 102A may be a base transceiver station (BTS) orcell site (a “cellular base station”) and may include hardware thatenables wireless communication with the UEs 106A through 106N.

The communication area (or coverage area) of the base station may bereferred to as a “cell.” The base station 102A and the UEs 106 may beconfigured to communicate over the transmission medium using any ofvarious radio access technologies (RATs), also referred to as wirelesscommunication technologies, or telecommunication standards, such as GSM,UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces),LTE, LTE-Advanced (LTE-A), 5G new radio (5G NR), HSPA, 3GPP2 CDMA2000(e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc.

As shown, the base station 102A may also be equipped to communicate witha network 100 (e.g., a core network of a cellular service provider, atelecommunication network such as a public switched telephone network(PSTN), and/or the Internet, among various possibilities). Thus, thebase station 102A may facilitate communication between the user devicesand/or between the user devices and the network 100. In particular, thecellular base station 102A may provide UEs 106 with varioustelecommunication capabilities, such as voice, SMS and/or data services.

Base station 102A and other similar base stations (such as base stations102B . . . 102N) operating according to the same or a different cellularcommunication standard may thus be provided as a network of cells, whichmay provide continuous or nearly continuous overlapping service to UEs106A-N and similar devices over a geographic area via one or morecellular communication standards.

Thus, while base station 102A may act as a “serving cell” for UEs 106A-Nas illustrated in FIG. 1 , each UE 106 may also be capable of receivingsignals from (and possibly within communication range of) one or moreother cells (which might be provided by base stations 102B-N and/or anyother base stations), which may be referred to as “neighboring cells.”Such cells may also be capable of facilitating communication betweenuser devices and/or between user devices and the network 100. Such cellsmay include “macro” cells, “micro” cells, “pico” cells, and/or cellswhich provide any of various other granularities of service area size.For example, base stations 102A-B illustrated in FIG. 1 might be macrocells, while base station 102N might be a micro cell. Otherconfigurations are also possible.

In some aspects, base station 102A may be a next generation basestation, e.g., a 5G New Radio (5G NR) base station, or “gNB.” In someaspects, a gNB may be connected to a legacy evolved packet core (EPC)network and/or to a NR core (NRC)/5G core (5GC) network. In addition, agNB cell may include one or more transition and reception points (TRPs).In addition, a UE capable of operating according to 5G NR may beconnected to one or more TRPs within one or more gNBs. For example, itmay be possible that that the base station 102A and one or more otherbase stations 102 support joint transmission, such that UE 106 may beable to receive transmissions from multiple base stations (and/ormultiple TRPs provided by the same base station). For example, asillustrated in FIG. 1 , both base station 102A and base station 102C areshown as serving UE 106A.

Note that a UE 106 may be capable of communicating using multiplewireless communication standards. For example, the UE 106 may beconfigured to communicate using a wireless networking (e.g., Wi-Fi)and/or peer-to-peer wireless communication protocol (e.g., Bluetooth,Wi-Fi peer-to-peer, etc.) in addition to at least one cellularcommunication protocol (e.g., GSM, UMTS (associated with, for example,WCDMA or TD-SCDMA air interfaces), LTE, LTE-A, 5G NR, HSPA, 3GPP2CDMA2000) (e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc.). The UE 106 mayalso or alternatively be configured to communicate using one or moreglobal navigational satellite systems (GNSS, e.g., GPS or GLONASS), oneor more mobile television broadcasting standards (e.g., ATSC-M/H),and/or any other wireless communication protocol, if desired. Othercombinations of wireless communication standards (including more thantwo wireless communication standards) are also possible.

Example User Equipment (UE)

FIG. 2 illustrates user equipment 106 (e.g., one of the devices 106Athrough 106N) in communication with a base station 102, according tosome aspects. The UE 106 may be a device with cellular communicationcapability such as a mobile phone, a hand-held device, a computer, alaptop, a tablet, a smart watch or other wearable device, or virtuallyany type of wireless device.

The UE 106 may include a processor (processing element) that isconfigured to execute program instructions stored in memory. The UE 106may perform any of the method aspects described herein by executing suchstored instructions. Alternatively, or in addition, the UE 106 mayinclude a programmable hardware element such as an FPGA(field-programmable gate array), an integrated circuit, and/or any ofvarious other possible hardware components that are configured toperform (e.g., individually or in combination) any of the method aspectsdescribed herein, or any portion of any of the method aspects describedherein.

The UE 106 may include one or more antennas for communicating using oneor more wireless communication protocols or technologies. In someaspects, the UE 106 may be configured to communicate using, for example,NR or LTE using at least some shared radio components. As additionalpossibilities, the UE 106 could be configured to communicate usingCDMA2000 (1×RTT/1×EV-DO/HRPD/eHRPD) or LTE using a single shared radioand/or GSM or LTE using the single shared radio. The shared radio maycouple to a single antenna, or may couple to multiple antennas (e.g.,for MIMO) for performing wireless communications. In general, a radiomay include any combination of a baseband processor, analog RF signalprocessing circuitry (e.g., including filters, mixers, oscillators,amplifiers, etc.), or digital processing circuitry (e.g., for digitalmodulation as well as other digital processing). Similarly, the radiomay implement one or more receive and transmit chains using theaforementioned hardware. For example, the UE 106 may share one or moreparts of a receive and/or transmit chain between multiple wirelesscommunication technologies, such as those discussed above.

In some aspects, the UE 106 may include separate transmit and/or receivechains (e.g., including separate antennas and other radio components)for each wireless communication protocol with which it is configured tocommunicate. As a further possibility, the UE 106 may include one ormore radios which are shared between multiple wireless communicationprotocols, and one or more radios which are used exclusively by a singlewireless communication protocol. For example, the UE 106 might include ashared radio for communicating using either of LTE or 5G NR (or eitherof LTE or 1×RTT, or either of LTE or GSM, among various possibilities),and separate radios for communicating using each of Wi-Fi and Bluetooth.Other configurations are also possible.

Example Communication Device

FIG. 3 illustrates an example simplified block diagram of acommunication device 106, according to some aspects. It is noted thatthe block diagram of the communication device of FIG. 3 is only oneexample of a possible communication device. According to aspects,communication device 106 may be a user equipment (UE) device, a mobiledevice or mobile station, a wireless device or wireless station, adesktop computer or computing device, a mobile computing device (e.g., alaptop, notebook, or portable computing device), a tablet, and/or acombination of devices, among other devices. As shown, the communicationdevice 106 may include a set of components 300 configured to performcore functions. For example, this set of components may be implementedas a system on chip (SOC), which may include portions for variouspurposes. Alternatively, this set of components 300 may be implementedas separate components or groups of components for the various purposes.The set of components 300 may be coupled (e.g., communicatively;directly or indirectly) to various other circuits of the communicationdevice 106.

For example, the communication device 106 may include various types ofmemory (e.g., including NAND flash 310), an input/output interface suchas connector I/F 320 (e.g., for connecting to a computer system; dock;charging station, input devices, such as a microphone, camera, keyboard;output devices, such as speakers; etc.), the display 360, which may beintegrated with or external to the communication device 106, andwireless communication circuitry 330 (e.g., for LTE, LTE-A, NR, UMTS,GSM, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, etc.). In some aspects,communication device 106 may include wired communication circuitry (notshown), such as a network interface card, e.g., for Ethernet.

The wireless communication circuitry 330 may couple (e.g.,communicatively; directly or indirectly) to one or more antennas, suchas antenna(s) 335 as shown. The wireless communication circuitry 330 mayinclude cellular communication circuitry and/or short to medium rangewireless communication circuitry, and may include multiple receivechains and/or multiple transmit chains for receiving and/or transmittingmultiple spatial streams, such as in a multiple-input multiple output(MIMO) configuration.

In some aspects, as further described below, cellular communicationcircuitry 330 may include one or more receive chains (including and/orcoupled to (e.g., communicatively; directly or indirectly) dedicatedprocessors and/or radios) for multiple RATs (e.g., a first receive chainfor LTE and a second receive chain for 5G NR). In addition, in someaspects, cellular communication circuitry 330 may include a singletransmit chain that may be switched between radios dedicated to specificRATs. For example, a first radio may be dedicated to a first RAT, e.g.,LTE, and may be in communication with a dedicated receive chain and atransmit chain shared with a second radio. The second radio may bededicated to a second RAT, e.g., 5G NR, and may be in communication witha dedicated receive chain and the shared transmit chain.

The communication device 106 may also include and/or be configured foruse with one or more user interface elements. The user interfaceelements may include any of various elements, such as display 360 (whichmay be a touchscreen display), a keyboard (which may be a discretekeyboard or may be implemented as part of a touchscreen display), amouse, a microphone and/or speakers, one or more cameras, one or morebuttons, and/or any of various other elements capable of providinginformation to a user and/or receiving or interpreting user input.

The communication device 106 may further include one or more smart cards345 that include SIM (Subscriber Identity Module) functionality, such asone or more UICC(s) (Universal Integrated Circuit Card(s)) cards 345.

As shown, the SOC 300 may include processor(s) 302, which may executeprogram instructions for the communication device 106 and displaycircuitry 304, which may perform graphics processing and provide displaysignals to the display 360. The processor(s) 302 may also be coupled tomemory management unit (MMU) 340, which may be configured to receiveaddresses from the processor(s) 302 and translate those addresses tolocations in memory (e.g., memory 306, read only memory (ROM) 350, NANDflash memory 310) and/or to other circuits or devices, such as thedisplay circuitry 304, wireless communication circuitry 330, connectorI/F 320, and/or display 360. The MMU 340 may be configured to performmemory protection and page table translation or set up. In some aspects,the MMU 340 may be included as a portion of the processor(s) 302.

As noted above, the communication device 106 may be configured tocommunicate using wireless and/or wired communication circuitry. Asdescribed herein, the communication device 106 may include hardware andsoftware components for implementing any of the various features andtechniques described herein. The processor 302 of the communicationdevice 106 may be configured to implement part or all of the featuresdescribed herein, e.g., by executing program instructions stored on amemory medium (e.g., a non-transitory computer-readable memory medium).Alternatively (or in addition), processor 302 may be configured as aprogrammable hardware element, such as an FPGA (Field Programmable GateArray), or as an ASIC (Application Specific Integrated Circuit).Alternatively (or in addition) the processor 302 of the communicationdevice 106, in conjunction with one or more of the other components 300,304, 306, 310, 320, 330, 340, 345, 350, 360 may be configured toimplement part or all of the features described herein.

In addition, as described herein, processor 302 may include one or moreprocessing elements. Thus, processor 302 may include one or moreintegrated circuits (ICs) that are configured to perform the functionsof processor 302. In addition, each integrated circuit may includecircuitry (e.g., first circuitry, second circuitry, etc.) configured toperform the functions of processor(s) 302.

Further, as described herein, wireless communication circuitry 330 mayinclude one or more processing elements. In other words, one or moreprocessing elements may be included in wireless communication circuitry330. Thus, wireless communication circuitry 330 may include one or moreintegrated circuits (ICs) that are configured to perform the functionsof wireless communication circuitry 330. In addition, each integratedcircuit may include circuitry (e.g., first circuitry, second circuitry,etc.) configured to perform the functions of wireless communicationcircuitry 330.

Example Base Station

FIG. 4 illustrates an example block diagram of a base station 102,according to some aspects. It is noted that the base station of FIG. 4is merely one example of a possible base station. As shown, the basestation 102 may include processor(s) 404 which may execute programinstructions for the base station 102. The processor(s) 404 may also becoupled to memory management unit (MMU) 440, which may be configured toreceive addresses from the processor(s)404 and translate those addressesto locations in memory (e.g., memory 460 and read only memory (ROM) 450)or to other circuits or devices.

The base station 102 may include at least one network port 470. Thenetwork port 470 may be configured to couple to a telephone network andprovide a plurality of devices, such as UE devices 106, access to thetelephone network as described above in FIGS. 1 and 2 .

The network port 470 (or an additional network port) may also oralternatively be configured to couple to a cellular network, e.g., acore network of a cellular service provider. The core network mayprovide mobility related services and/or other services to a pluralityof devices, such as UE devices 106. In some cases, the network port 470may couple to a telephone network via the core network, and/or the corenetwork may provide a telephone network (e.g., among other UE devicesserviced by the cellular service provider).

In some aspects, base station 102 may be a next generation base station,e.g., a 5G New Radio (5G NR) base station, or “gNB.” In such aspects,base station 102 may be connected to a legacy evolved packet core (EPC)network and/or to a NR core (NRC)/5G core (5GC) network. In addition,base station 102 may be considered a 5G NR cell and may include one ormore transition and reception points (TRPs). In addition, a UE capableof operating according to 5G NR may be connected to one or more TRPswithin one or more gNBs.

The base station 102 may include at least one antenna 434, and possiblymultiple antennas. The at least one antenna 434 may be configured tooperate as a wireless transceiver and may be further configured tocommunicate with UE devices 106 via radio 430. The antenna 434communicates with the radio 430 via communication chain 432.Communication chain 432 may be a receive chain, a transmit chain orboth. The radio 430 may be configured to communicate via variouswireless communication standards, including, but not limited to, 5G NR.LTE, LTE-A. GSM, UMTS. CDMA2000, Wi-Fi, etc.

The base station 102 may be configured to communicate wirelessly usingmultiple wireless communication standards. In some instances, the basestation 102 may include multiple radios, which may enable the basestation 102 to communicate according to multiple wireless communicationtechnologies. For example, as one possibility, the base station 102 mayinclude an LTE radio for performing communication according to LTE aswell as a 5G NR radio for performing communication according to 5G NR.In such a case, the base station 102 may be capable of operating as bothan LTE base station and a 5G NR base station. As another possibility,the base station 102 may include a multi-mode radio, which is capable ofperforming communications according to any of multiple wirelesscommunication technologies (e.g., 5G NR and LTE, 5G NR and Wi-Fi, LTEand Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, etc.).

As described further subsequently herein, the BS 102 may includehardware and software components for implementing or supportingimplementation of features described herein. The processor 404 of thebase station 102 may be configured to implement or supportimplementation of part or all of the methods described herein, e.g., byexecuting program instructions stored on a memory medium (e.g., anon-transitory computer readable memory medium). Alternatively, theprocessor 404 may be configured as a programmable hardware element, suchas an FPGA (Field Programmable Gate Array), or as an ASIC (ApplicationSpecific Integrated Circuit), or a combination thereof. Alternatively(or in addition) the processor 404 of the BS 102, in conjunction withone or more of the other components 430, 432, 434, 440, 450, 460, 470may be configured to implement or support implementation of part or allof the features described herein.

In addition, as described herein, processor(s) 404 may include one ormore processing elements. Thus, processor(s) 404 may include one or moreintegrated circuits (ICs) that are configured to perform the functionsof processor(s) 404. In addition, each integrated circuit may includecircuitry (e.g., first circuitry, second circuitry, etc.) configured toperform the functions of processor(s) 404.

Further, as described herein, radio 430 may include one or moreprocessing elements. Thus, radio 430 may include one or more integratedcircuits (ICs) that are configured to perform the functions of radio430. In addition, each integrated circuit may include circuitry (e.g.,first circuitry, second circuitry, etc.) configured to perform thefunctions of radio 430.

Example Cellular Communication Circuitry

FIG. 5 illustrates an example simplified block diagram of cellularcommunication circuitry, according to some aspects. It is noted that theblock diagram of the cellular communication circuitry of FIG. 5 is onlyone example of a possible cellular communication circuit; othercircuits, such as circuits including or coupled to sufficient antennasfor different RATs to perform uplink activities using separate antennas,or circuits including or coupled to fewer antennas, e.g., that may beshared among multiple RATs, are also possible. According to someaspects, cellular communication circuitry 330 may be included in acommunication device, such as communication device 106 described above.As noted above, communication device 106 may be a user equipment (UE)device, a mobile device or mobile station, a wireless device or wirelessstation, a desktop computer or computing device, a mobile computingdevice (e.g., a laptop, notebook, or portable computing device), atablet and/or a combination of devices, among other devices.

The cellular communication circuitry 330 may couple (e.g.,communicatively; directly or indirectly) to one or more antennas, suchas antennas 335 a-b and 336 as shown. In some aspects, cellularcommunication circuitry 330 may include dedicated receive chains(including and/or coupled to (e.g., communicatively; directly orindirectly) dedicated processors and/or radios) for multiple RATs (e.g.,a first receive chain for LTE and a second receive chain for 5G NR). Forexample, as shown in FIG. 5 , cellular communication circuitry 330 mayinclude a first modem 510 and a second modem 520. The first modem 510may be configured for communications according to a first RAT, e.g.,such as LTE or LTE-A, and the second modem 520 may be configured forcommunications according to a second RAT, e.g., such as 5G NR.

As shown, the first modem 510 may include one or more processors 512 anda memory 516 in communication with processors 512. Modem 510 may be incommunication with a radio frequency (RF) front end 530. RF front end530 may include circuitry for transmitting and receiving radio signals.For example, RF front end 530 may include receive circuitry (RX) 532 andtransmit circuitry (TX) 534. In some aspects, receive circuitry 532 maybe in communication with downlink (DL) front end 550, which may includecircuitry for receiving radio signals via antenna 335 a.

Similarly, the second modem 520 may include one or more processors 522and a memory 526 in communication with processors 522. Modem 520 may bein communication with an RF front end 540. RF front end 540 may includecircuitry for transmitting and receiving radio signals. For example, RFfront end 540 may include receive circuitry 542 and transmit circuitry544. In some aspects, receive circuitry 542 may be in communication withDL front end 560, which may include circuitry for receiving radiosignals via antenna 335 b.

In some aspects, a switch 570 may couple transmit circuitry 534 touplink (UL) front end 572. In addition, switch 570 may couple transmitcircuitry 544 to UL front end 572. UL front end 572 may includecircuitry for transmitting radio signals via antenna 336. Thus, whencellular communication circuitry 330 receives instructions to transmitaccording to the first RAT (e.g., as supported via the first modem 510),switch 570 may be switched to a first state that allows the first modem510 to transmit signals according to the first RAT (e.g., via a transmitchain that includes transmit circuitry 534 and UL front end 572).Similarly, when cellular communication circuitry 330 receivesinstructions to transmit according to the second RAT (e.g., as supportedvia the second modem 520), switch 570 may be switched to a second statethat allows the second modem 520 to transmit signals according to thesecond RAT (e.g., via a transmit chain that includes transmit circuitry544 and UL front end 572).

As described herein, the first modem 510 and/or the second modem 520 mayinclude hardware and software components for implementing any of thevarious features and techniques described herein. The processors 512,522 may be configured to implement part or all of the features describedherein, e.g., by executing program instructions stored on a memorymedium (e.g., a non-transitory computer-readable memory medium).Alternatively (or in addition), processors 512, 522 may be configured asa programmable hardware element, such as an FPGA (Field ProgrammableGate Array), or as an ASIC (Application Specific Integrated Circuit).Alternatively (or in addition) the processors 512, 522, in conjunctionwith one or more of the other components 530, 532, 534, 540, 542, 544,550, 570, 572, 335 and 336 may be configured to implement part or all ofthe features described herein.

In addition, as described herein, processors 512, 522 may include one ormore processing elements. Thus, processors 512, 522 may include one ormore integrated circuits (ICs) that are configured to perform thefunctions of processors 512, 522. In addition, each integrated circuitmay include circuitry (e.g., first circuitry, second circuitry, etc.)configured to perform the functions of processors 512, 522.

In some aspects, the cellular communication circuitry 330 may includeonly one transmit/receive chain. For example, the cellular communicationcircuitry 330 may not include the modem 520, the RF front end 540, theDL front end 560, and/or the antenna 335 b. As another example, thecellular communication circuitry 330 may not include the modem 510, theRF front end 530, the DL front end 550, and/or the antenna 335 a. Insome aspects, the cellular communication circuitry 330 may also notinclude the switch 570, and the RF front end 530 or the RF front end 540may be in communication, e.g., directly, with the UL front end 572.

Example Network Element

FIG. 6 illustrates an exemplary block diagram of a network element 600,according to some aspects. According to some aspects, the networkelement 600 may implement one or more logical functions/entities of acellular core network, such as a mobility management entity (MME),serving gateway (S-GW), access and management function (AMF), sessionmanagement function (SMF), network slice quota management (NSQM)function, etc. It is noted that the network element 600 of FIG. 6 ismerely one example of a possible network element 600. As shown, the corenetwork element 600 may include processor(s) 604 which may executeprogram instructions for the core network element 600. The processor(s)604 may also be coupled to memory management unit (MMU) 640, which maybe configured to receive addresses from the processor(s)604 andtranslate those addresses to locations in memory (e.g., memory 660 andread only memory (ROM) 650) or to other circuits or devices.

The network element 600 may include at least one network port 670. Thenetwork port 670 may be configured to couple to one or more basestations and/or other cellular network entities and/or devices. Thenetwork element 600 may communicate with base stations (e.g., eNBs/gNBs)and/or other network entities/devices by means of any of variouscommunication protocols and/or interfaces.

As described further subsequently herein, the network element 600 mayinclude hardware and software components for implementing and/orsupporting implementation of features described herein. The processor(s)604 of the core network element 600 may be configured to implement orsupport implementation of part or all of the methods described herein,e.g., by executing program instructions stored on a memory medium (e.g.,a nontransitory computer-readable memory medium). Alternatively, theprocessor 604 may be configured as a programmable hardware element, suchas an FPGA (Field Programmable Gate Array), or as an ASIC (ApplicationSpecific Integrated Circuit), or a combination thereof. The networkelement 600 may operate according to the various methods as disclosedherein for wireless devices to perform cell measurements usingconfigured reference signals while in an inactive state in a cellularcommunication system.

Radio Resource Control (RRC) IDLE and INACTIVE States

Multiple cellular communication technologies include the use of a radioresource control (RRC) protocol, e.g., which may facilitate connectionestablishment and release, radio bearer establishment, reconfiguration,and release, and/or various other possible signaling functionssupporting the air interface between a wireless device and a cellularbase station.

A wireless device may commonly operate in one of multiple possiblestates with respect to RRC. For example, in LTE, a wireless device mayoperate in an RRC connected state (e.g., in which the wireless devicecan perform continuous data transfer, and in which handover betweencells is managed by the network and access stratum (AS) contextinformation is retained for the wireless device), or in an RRC idlestate (e.g., in which the wireless device may operate in a more batteryefficient state when not performing continuous data transfer, in whichthe wireless device may handle it's cell re-selection activities, and inwhich the network may not retain AS context information for the wirelessdevice).

In addition to RRC connected and RRC idle states, it may also bepossible to support one or more other types of RRC states for a wirelessdevice, at least according to some aspects. For example, for NR, an RRCinactive state in which a wireless device may be able to operate in arelatively battery efficient state while the network also retains atleast some AS context information may be supported. In some aspects, thewireless device may maintain a non-access stratum connection (NAS) withthe CN and RRC configuration as before the UE entered the inactivestate. In certain cases, dedicated AS resources may not be allocated tothe UE in the inactive state. At least according to some aspects, such astate may employ wireless device based mobility, e.g., such that awireless device can move within a radio access network notification area(RNA) without notifying the next generation (NG) radio access network(RAN). While in this state, a wireless device may perform cellre-selection and system information acquisition for itself. At the sametime, the last serving base station (e.g., gNB) may keep the wirelessdevice context and the NG connection with the 5G core network (CN)associated with the wireless device, e.g., to facilitate easiertransition back to an RRC connected state. When paging a wireless devicein RRC inactive state, RNA specific parameters may be used by the RAN,for example including a UE specific DRX and UE Identity Index value(e.g., I-RNTI).

A wireless device operating in such an RRC inactive state may performRNA updates periodically (e.g., based on a configured periodic RNAupdate timer) and/or in an event based manner, e.g., w % ben thewireless device moves out of its current configured RNA to a differentRNA, according to some aspects.

Use of an RRC inactive state may help reduce the network signalingoverhead for a wireless device's connection, at least in some instances.For example, for a wireless device with infrequent data transmissions,utilizing such an RRC inactive state may reduce the amount of mobilityrelated signaling (e.g., for handovers) needed compared to an RRCconnected state, e.g., since the wireless device may be able to manageits own cell re-selection process when moving between cells. For such awireless device, utilizing an RRC inactive state may also reduce theamount of connection setup related signaling needed compared to an RRCidle state, e.g., since the network may retain at least some contextinformation for the wireless device. This may directly reduce thesignaling latency associated with a transition to an RRC connectedstate.

As another potential benefit, such a state may reduce the control planedelay for a wireless device, e.g., in comparison to operating in an RRCidle state. For example, a reduced access stratum connection setupperiod and/or non-access stratum connection setup period may be possiblefor an RRC inactive state relative to an RRC idle state. The time tomove from a battery efficient state to the start of continuous datatransfer may thus be reduced.

Additionally, such a state may improve the power saving capability of awireless device, e.g., in comparison to operating in an RRC connectedstate. For example, while in RRC connected state, serving and/orneighboring cell measurements may be required more frequently than whilein RRC inactive state, e.g., at least in line with a connected modediscontinuous reception (C-DRX) period of the wireless device.

The wireless device may manage cell re-selection while in an RRCinactive state. A goal of the cell re-selection process may includekeeping a wireless device camped on a suitable cell, which may include acell with sufficient signal strength, signal quality, and/or othercharacteristics such that the wireless device may be able toestablish/activate a connection and perform data transfer via the cell.Cell re-selection may include either or both of intra-frequency cellre-selection or inter-frequency cell re-selection. As part of cellre-selection process while in such an RRC inactive state, a wirelessdevice may perform cell measurements on serving and/or neighboringcells. The manner in which these cell measurements are performed canpotentially have a substantial impact on wireless device powerconsumption and the amount of time needed to access continuous datatransfer capability (e.g., by resuming operation in RRC connectedstate). For example, if synchronization signal blocks (SSBs) are used toperform cell measurements, there may be a delay between a wirelessdevice's inactive state wakeup instance and the next SSB burst, and/ormeasurements may be performed over a relatively long period of time toallow for receiver beam sweeping over multiple SSB bursts. Further, suchSSB bursts may be performed at a different frequency and/or at a widerbandwidth than the wireless device's specified inactive state wakeupinstance. Alternatively, a cellular base station could provide paginginstances that are aligned with SSBs in time and/or frequency domains,e.g., to facilitate reduced wireless device power consumption in RRCinactive state.

FIG. 7 is a communications flow diagram illustrating a communicationsflow 700 for entering and resuming from an RRC inactive state, inaccordance with aspects of the present disclosure. Aspects of thecommunications flow may be implemented by a wireless device, e.g., inconjunction with a one or more wireless devices and one or more portionsof a core network (CN), such as a UE 702, gNB 704, last serving gNB 706,and Access and Mobility Functions (AMF) 708 illustrated in and describedwith respect to FIG. 7 , or more generally in conjunction with any ofthe computer circuitry, systems, devices, elements, or components shownin the above Figures, among others, as desired. For example, a processor(and/or other hardware) of such a device may be configured to cause thedevice to perform any combination of the illustrated method elementsand/or other method elements.

In the communications flow 700, the wireless device, such as UE 702,receives, for example, an RRC release message from a last serving gNB706 (Step 1). The RRC release message may include suspend configurationinformation for entering the RRC inactive state by the UE 702. Thesuspend configuration information may include information for operatingin and/or resuming the connection from the RRC inactive state, such asinformation about a RNA and security parameters for supporting anencrypted resume message, such as a UE identifier and resume securityinformation. An RNA may comprise an area associated with a set of gNBswithin which the UE is allowed to move without having to notify thenetwork.

In certain cases, the UE 702 may want to perform a dedicated datatransmission/reception which cannot be performed in the inactive state.To exit the inactive state, the UE 702 may initiate an RRC resumeprocedure by transmitting a RRC resume request to a gNB, in thisexample, gNB 704, which is a different gNB than the last serving gNB 706(Step 2). The RRC resume request may include, for example, the UEidentifier and resume security information. The gNB 704 may thenretrieve a context for the UE 702 from the last serving gNB (Step 3).After receiving the UE context (Step 4) the gNB 704 may send the UE 702a RRC resume message in response to the RRC resume request (Step 5). TheUE 702 may then transition to an RRC connected state 710 and send a RRCresume complete message to the gNB 704 (Step 6).

The gNB 704 then performs a UE handover from the last serving gNB 706 bysending a data forwarding address indication to the last serving gNB(Step 7) and a path switch request to the AMF 708 (Step 8). The AMF 708responds with a path switch request response (Step 9) and the gNB sendsa UE context release to the last serving gNB 706 (Step 10).

In certain wireless communication networks, ciphering and/or integrityprotection may be used to help provide data integrity and security. Forexample, in 5G NR, user data in data radio bearers (DRBs) blocks may beciphered to provide data confidentiality and integrity protection foruser data. Additionally. RRC signaling in signaling radio bearers (SRBs)blocks are separately ciphered from user data to help provide signalingdata confidentiality and wireless network integrity. Keys used for NASlevel security as between the CN and wireless devices are thuscryptographically separated from AS keys used, for example, RRCsignaling. In certain cases, a sequence number may be used as an inputto the ciphering and/or integrity protection. For example, a next hop(NH) chaining counter (NCC) sequence number may be used in conjunctionwith a NH parameter value to generate a key for use between a UE and agNB (K_(gNB)). The NH parameter value may be computed by the AMF and theUE, but not by the gNB, and the NCC sequence number may be provided bythe AMF (as discussed in more detail below).

FIG. 8 is a communications flow diagram illustrating a communicationsflow 800 for entering and resuming from an RRC inactive state, inaccordance with aspects of the present disclosure. In communicationsflow 800, UE 802 receives an RRC release message from gNB1 804. Incertain cases, the RRC release message includes suspend configurationinformation along with resume security information including a first NCCsequence number. The gNB1 804 may obtain the NCC and corresponding NHparameter pair, for example, from the AMF 810, prior to transmitting theRRC release message to the UE 802 (not shown). After receiving the RRCrelease message from the gNB1 804, the UE 802 may enter the RRC inactivestate. After determining that the UE needs to exit the RRC inactivestate, the UE 802 may derive 812 a gNB key (K_(gNB)*) for use between UE802 and a target gNB within the UE's RNA before transmitting an RRCresume message to the target gNB, in this case, target gNB2 806. The RRCresume message may be ciphered and/or integrity protected using thederived gNB key (K_(gNB)*) and may include security information, such asan authentication token. The gNB key (K_(gNB)*) may be derived based onthe target gNB information. As an example, the target gNB informationmay include the target gNB2's 806 physical cell ID (PCI), cell-identity(Cell-ID), and cell radio network temporary identifier (C-RNTI).

After receiving the RRC resume message, the target gNB 806 forwards thesecurity information along with target gNB 806 information to the sourcegNB (e.g., the gNB which was previously communicating with the UE), heregNB1 804 (not shown). The source gNB1 804 then calculates the gNB key(K_(gNB)*) based on, among other variables, the target gNB2 806information and the NCC/NH parameter pair. The source gNB1 804 may thentransmit back to the target gNB2 806 the calculated gNB key (K_(gNB)*)along with the NCC associated with the gNB key (K_(gNB)*), cipheringand/integrity protection algorithm, security policy, and other securityinformation (not shown).

The target gNB2 806 may also send a path switch request to the AMF toinitiate a handover of the UE 802 from the source gNB1 804 to the targetgNB2 806. The AMF may response with a path switch response acknowledgethe handover and providing to the target gNB 806 a second NCC2 andcorresponding second NH₂ parameter pair. The target gNB2 806 may send anRRC resume procedure message back to the UE 802 and communicates withthe UE 802 in a RRC connected state using the calculated gNB key(K_(gNB)*). After communicating, the UE 802 may to return to an RRCinactive state 814 after receiving a second RRC release message from thetarget gNB2 806. The second RRC release message may also include suspendconfiguration information along with resume security informationincluding the second NCC2 and the corresponding second NH₂ parameterpair.

Similarly, to exit the RRC inactive state, the UE 802 may derive asecond gNB key (K_(gNB2)*) for use between UE 802 and a second targetgNB3 808, also within the UE's RNA. The gNB key (K_(gNB2)*) may bederived based on the target gNB information, which may include, forexample, the target gNB3's 806 PCI, Cell-ID, C-RNTI. The UE 802 may thentransmit a second RRC resume message to target gNB 3 808 using thesecond gNB key (K_(gNB2)*). This second RRC resume message may alsoinclude security information, such as an authentication token. Afterreceiving the second RRC resume message, the target gNB3 forwards thesecurity information along with second target gNB3 808 information to asecond source gNB, now gNB2 806 as the UE was handed over from gNB1 togNB2 previously. The second source gNB2 806 then calculates the secondgNB key (K_(gNB2)*) based on, among other variables, the second targetgNB3 808 information and the NCC/NH parameter pair. The second sourcegNB2 806 may then transmit back to the second target gNB3 808 thecalculated second gNB key (K_(gNB2)*) along with the NCC associated withthe second gNB key (K_(gNB2)*), ciphering and/or integrity protectionalgorithm, security policy, and other security information (not shown).The second target gNB3 808 may also send a path switch request to theAMF to initiate a second handover of the UE 802 from the second sourcegNB2 806 to the second target gNB2 808. The AMF may response with a pathswitch response acknowledge the handover and providing to the secondtarget gNB 808 a third NCC₃ and corresponding third NH₃ parameter pair.The second target gNB 808 may send an RRC resume procedure message backto the UE 802 and communicates with the UE 802 in a RRC connected stateusing the second calculated gNB key (K_(gNB2)*). After communicating,the UE 802 may to return to the RRC inactive state after receiving athird RRC release message from the second target gNB1 808. The third RRCrelease message may also include suspend configuration information alongwith resume security information including the third NCC₃ and thecorresponding third NH₃ parameter pair.

FIG. 9 is a diagram illustrating key derivation 900, in accordance withaspects of the present disclosure. As a part of initially setting up ASkeys, a UE and an AMF may share an AMF key K_(AMF) from which an initialgNB key K_(gNB) 902 and a first NH 904 parameter may be derived from byboth the UE and the AMF. The initial gNB key K_(gNB) 902 may be derivedin part based on a NAS uplink count with the CN. This initial gNB keyK_(gNB) 902 may be associated with an NCC=0, while the first NH 904 maybe derived from the initial gNB key K_(gNB) 902 and is associated withNCC=1.

After this initial setup, this first pair of gNB key and NH parameter,initial K_(gNB) 902 and first NH 904, will not be used to derive a gNBkey. To derive a new gNB key, two techniques may be used. Verticalderivation of a new gNB key may be performed when there is an unusedNCC/NH pair at the gNB. As discussed above, a gNB may obtain NH/NCCpairs from the AMF and if the gNB has an unused NH/NCC pair, the gNB mayvertically derive a new gNB key K_(gNB) using the unused NH 906 alongwith gNB information, such as PCI, Cell-ID. C-RNTI, etc. The gNB mayalso provide the NCC/NH pair to the UE, to derive the new gNB keyK_(gNB). Horizontal derivation of a new gNB key may be performed ifthere are no unused NCC/NH pairs available at the gNB. Horizontalderivation is based on a currently active gNB key, called K_(NG-RAN)along with gNB information. A gNB may signal to a UE to use verticalderivation or horizontal derivation of the new gNB key in the RRCrelease message. If the NCC included in the RRC release message matchesthe NCC value currently in use, then the new gNB key may be derivedusing horizontal derivation. If the NCC value included in the RRCrelease message is a new NCC value, then the new gNB key may be derivedusing vertical derivation.

UE Data Transmission in an RRC Inactive State

In certain cases, it may be desirable to allow a UE to transmit UL datawhile remaining in the RRC inactive state and without transitioning tothe RRC connected state. To transmit in the RRC inactive state, the UEwould not send an RRC resume request prior to transmitting UL data. Atarget gNB that is within the UE's configured RNA, but is not theprevious serving gNB, would not be able to retrieve NCC and calculatedgNB key from the original serving gNB prior to the UL and it may bedesirable to provide an improved technique for key generation fortransmissions while in an inactive state.

FIG. 10 is a communications flow diagram illustrating techniques 1000for key generation for inactive state data transmissions, in accordancewith aspects of the present disclosure. In certain cases, key generationfor inactive state data transmissions may be performed using a singleNCC value to generate keys for multiple gNBs. In these cases, multiplenew gNB values may be derived from the single NCC value included in theRRC release message. This NCC value may be either a new NCC value or anNCC value currently in use. There may be multiple options for derivingmultiple new gNB keys from the single NCC value.

In a first option 1002, the last gNB key from the last serving cell maybe reused for each data transmission in the RRC inactive state. In thefirst option 1002, the UE 802 receives an NCC value from a source gNB1804 in the RRC release message and derives a gNB key (K_(gNB)) based onthe received NCC value and stores the derived gNB key (K_(gNB)). The UE802 may then transmit data ciphered and/or integrity protected with thederived gNB key (K_(gNB)) while in the RRC inactive state to a targetgNB2 806, which is different from the source gNB1 804 and within theUE's configured RNA. The UE 802 may also transmit data ciphered and/orintegrity protected using the same stored derived gNB key (K_(gNB)) toanother target gNB3 808 within the UE's configured RNA, which isdifferent from the source gNB1 804 and the target gNB2 806, and withinthe UE's configured RNA. Of note, the same gNB key (K_(gNB)) is used tocipher and/or integrity protect data to multiple gNBs in the firstoption 1002.

As discussed above, the source gNB 804 receives an NCC/NH pair from AMFto derive the gNB key (K_(gNB)). This NCC/NH pair is only provided tothe source gNB 804 from the AMF. For each option, on the network side,data security handing may be provided by the source gNB or data securitymay be performed by each accessed gNB. In the first option 1002, if datasecurity is handled by the source gNB1 804, when the data transmitted bythe UE 802 in the inactive state to a target gNB, such as either targetgNB2 806 or target gNB3 808, the target gNB forwards the securityinformation of the data transmitted along with target gNB information tothe source gNB1 804. The source gNB1 804 then returns the derived gNBkey (K_(gNB)) to the target gNB. If data security is handled by eachaccessed gNB, the source gNB1 804, after transmitting the RRC releasemessage, including RNA information, to the UE 802, may broadcast UEcontext information including the derived gNB key to the other gNBs inthe configured RNA of the UE 802. Then, when the UE 802 transmits datato, for example target gNB3 808, in the inactive state, the target gNB3808 will have the derived gNB key (K_(gNB)) to decrypt transmitted ASdata.

In certain cases, a second option 1004 may be used to derive a new gNBkey (K_(gNB*)) for each data transmission in the RRC inactive state. Inthe second option 1004, the UE 802 also receives an NCC value from asource gNB1 804. For each data transmission in the RRC inactive state,the UE derives a new gNB key (K_(gNB*)) using horizontal derivation. Thehorizontal derivation may be based on the currently active gNB key(K_(NG-RAN)) based on the received NCC value, along with gNB informationof the target gNB. For example, the UE 802 receives an NCC value from asource gNB1 804 in the RRC release message and derives a gNB key(K_(NG-RAN)) based on the received NCC value. When the UE 802 wants totransmit data in the inactive state, the UE 802 selects a target gNB,such as target gNB2 806 and obtains gNB information, such as PCI,Cell-ID, C-RNTI, etc., broadcast by the target gNB2 806. The UE 802 thenhorizontally derives a new gNB key (K_(gNB2*)) based on the gNBinformation and derived gNB key (K_(NG-RAN)). For each additionaltransmission, the UE horizontally derives another new gNB key(K_(gNB2*)). If the UE 802 wants to transmit in the inactive state toanother target gNB, such as target gNB3 808, the UE 802 horizontallyderives a new gNB key (K_(gNB3*)) for the target gNB3 808 based on thegNB information for the target gNB3 808.

For the second option 1004, on the network side, data security handingagain may be provided by the source gNB or data security may beperformed by each accessed gNB in a manner similar to that discussedabove with respect to the first option 1002.

In certain cases, a third option 1006 may be used to vertically derive anew gNB key (K_(gNB)) for data transmissions in the RRC inactive state.This new gNB key (K_(gNB)) may be used for all data transmission in theRRC inactive state. As an example, the UE 802 receives an NCC value froma source gNB1 804 in the RRC release message. In certain cases, the UE802 may vertically derive a new gNB key (K_(gNB)) based on the NCC valueand gNB information of the target gNB2 806. In other cases, the UE 802may determine an initial target gNB, such as target gNB2 806, fortransmitting data to in the RRC inactive state and obtain gNBinformation broadcast by the target gNB2 806. In this example, theinitial target gNB may be the first gNB that the UE 802 transmits to inthe inactive state. The UE 802 may then vertically derive a new gNB key(K_(gNB)) based on the NCC value and the obtained gNB information of thetarget gNB2 806. The UE 802 may then reuse the derived new gNB key(K_(gNB)) for each subsequent data transmission. Continuing the previousexample, the UE 802 may then use the previously derived new gNB key(K_(gNB)) to transmit data in the RRC inactive state to another targetgNB, such as target gNB3 808.

For the third option 1006, on the network side, data security handingagain may be provided by the source gNB or data security may beperformed by each accessed gNB in a manner similar to that discussedabove with respect to the first option 1002. In addition, data securitymay be performed by the source gNB and the initial target gNB. Forexample, the initial target gNB, such as target gNB2 806, may forwardthe security information of the data transmitted by the UE 802 alongwith initial target gNB information to the source gNB1 804. The sourcegNB1 804 then returns the derived gNB key (K_(gNB)) to the initialtarget gNB. The source gNB 806 or initial target gNB2 may then broadcastthe derived gNB key (K_(gNB)) to the other gNBs of the UE's RNA.

In certain cases, a fourth option 1008 may be used to vertically derivea new gNB key (K_(gNB)) for each data transmissions in the RRC inactivestate. As an example, the serving gNB1 804 receives an NCC value and NHparameter pair from the AMF. The UE 802 receives an NCC value from thesource gNB1 804 in the RRC release message. When the UE 802 wants totransmit data in the inactive state, the UE 802 selects a target gNB,such as target gNB2 806, and obtain gNB information, broadcast by thetarget gNB2 806. The UE 802 may then vertically derive a new gNB key(K_(gNB2*)) based on the NCC value and the obtained gNB information ofthe target gNB2 806. The UE 802 may then transmit data to the targetgNB2 806 using the vertically derived new gNB key (K_(gNB2*)). Thetarget gNB2 806 may then forward the security information from thereceived data and gNB information to the source gNB1 804 and the sourcegNB1 804 may then return the derived gNB key (K_(gNB2)) to the targetgNB2 806. In other cases, data security may be performed by eachaccessed gNB in a manner similar to that discussed above with respect tothe first option 1002 where the source gNB1 804 may broadcast the NCCvalue and NH parameter pair to the other gNBs in the configured RNA ofthe UE 802. If the UE 802 wants to transmit data in the inactive stateto another target gNB, for example target gNB3 808, the UE 802 obtainsgNB information of the target gNB3 808, vertically derives a new gNB key(K_(gNB3*)) based on the previously obtained NCC value and the obtainedgNB information of the target gNB3 808, and transmits the data to thetarget gNB3 808. The target gNB3 808 may then either obtained thederived gNB key (K_(gNB3)) from the source gNB1 804 or derive the gNBkey (K_(gNB3)) from the broadcast NCC value and NH parameters in amanner similar to that described for target gNB2 806 above.

In certain cases, a fifth option 1010 may be used to vertically andhorizontally derive new gNB keys (K_(gNB*)) for data transmissions inthe RRC inactive state. In the fifth option 1010, a new gNB key(K_(gNB*)) may be derived for each data transmission where the new gNBkey (K_(gNB*)) is vertically derived for the initial transmission, andhorizontally derived for subsequent data transmissions. As an example,the serving gNB1 804 receives an NCC value and NH parameter pair fromthe AMF. The UE 802 receives an NCC value from the source gNB1 804 inthe RRC release message. When the UE 802 wants to transmit data in theinactive state, the UE 802 selects a target gNB, such as target gNB2806, and obtain gNB information, broadcast by the target gNB 806. The UE802 may then vertically derive a new gNB key (K_(gNB2*)) based on theNCC value and the obtained gNB information of the target gNB2 806. Ifthe UE 802 wants to transmit more data in the inactive state, the UE 802may select another target gNB, such as target gNB3 808, obtain gNBinformation from the target gNB3 808, and horizontally derive a new gNBkey (K_(gNB3*)) based on the previous gNB key, NCC value, and gNBinformation from the target gNB3 808.

For the fifth option 1010, on the network side, data security handingagain may be provided by the source gNB or data security may beperformed by each accessed gNB in a manner similar to that discussedabove with respect to the first option 1002 and fourth option 1008.

FIG. 11 is a communications flow diagram illustrating a communicationsflow 1100 for entering and resuming from an RRC inactive state, inaccordance with aspects of the present disclosure. The communicationsflow 1100 illustrates an example corresponding to the fourth option 1008and where data security is handled by each accessed gNB, as discussed inconjunction with FIG. 10 . In this example, the serving gNB1 1104receives a first NCC value and NH parameter pair from the AMF (notshown). The serving gNB1 1104 then transmits RRC release message to theUE 1102 with the first NCC value and suspend configuration informationincluding RNA information. The serving gNB1 1104 then sends UE contextinformation including the received first NCC value and NH parameter pairto other gNBs in the RNA of the UE 1102, such as target gNB2 1106 andtarget gNB3 1109. The other gNBs may then vertically derive new gNB keys(K_(gNB*)) based on the received first NCC value, NH parameter, andtheir gNB information. When the UE 1102 wants to transmit data in theinactive state, the UE 1102 selects a target gNB, such as target gNB21106, and obtains gNB information, broadcast by the target gNB2 1106.The UE 1102 may then vertically derive a new gNB key (K_(gNB2*)) basedon the NCC value and the obtained gNB information of the target gNB21106. The UE 1102 may then transmit data to the target gNB2 1106 usingthe vertically derived new gNB key (K_(gNB2*)). The target gNB2 1106derives 1112 the new gNB key (K_(gNB2*)) as discussed above to access ASdata received from the UE 1102. Similarly, when the UE 1102 wants totransmit data in the active state to target gNB3 1108, the UE 1108 mayvertically derive another new gNB key (K_(gNB3*)) based on the NCC valueand the obtained gNB information of the target gNB8 1108. The targetgNB8 1108 derives 1114 the new gNB key (K_(gNB3*)) as discussed above toaccess AS data received from the UE 1102. In certain cases, the UE 1102may want to transition to a connected state on a target gNB2 1106different from the source gNB1 1104. In such cases, the UE 1102 mayperform an RRC resume procedure in a manner similar to that describedabove in conjunction with FIG. 7 . The UE 1102 may also return to theinactive state in a manner similar to that described above inconjunction with FIG. 7 .

FIG. 12 is a communications flow diagram illustrating a communicationsflow 1200 for entering and resuming from an RRC inactive state, inaccordance with aspects of the present disclosure. The communicationsflow 1200 illustrates an example corresponding to the fourth option 1008and where data security is handled by the source gNB, as discussed inconjunction with FIG. 10 . In this example, the serving gNB1 1104receives a first NCC value and NH parameter pair from the AMF (notshown). The serving gNB1 1104 then transmits RRC release message to theUE 1102 with the first NCC value and suspend configuration informationincluding RNA information. After the data transmitted by the UE 1102 inthe inactive state is received by a target gNB, such as either targetgNB2 1106, the target gNB forwards the security information along withtarget gNB information to the source gNB1 1104. The source gNB1 1104then vertically derives 1202 a new gNB key (K_(gNB2*)) based on thetarget gNB information, the first NCC value, and NH parameter andtransmits the derived new gNB key (K_(gNB*)) to the target gNB2 1106.Similarly, the source gNB1 1104 may vertically derive 1204 another newgNB key (K_(gNB2*)) for another target gNB3 1108 of the UE's RNA when UEcontext information is requested by the other target gNB3 1108. Incertain cases, the UE 1102 may want to transition to a connected stateon a target gNB2 1106 different from the source gNB1 1104. In suchcases, the UE 1102 may perform an RRC resume procedure in a mannersimilar to that described above in conjunction with FIG. 7 . The UE 1102may also return to the inactive state in a manner similar to thatdescribed above in conjunction with FIG. 7 .

FIG. 13 is a communications flow diagram illustrating a communicationsflow 1300 for entering and resuming from an RRC inactive state, inaccordance with aspects of the present disclosure. The communicationsflow 1300 illustrates an example corresponding to the fifth option 1010and where data security is handled by the source gNB, as discussed inconjunction with FIG. 10 . In this example, the serving gNB1 1104receives a first NCC value and NH parameter pair from the AMF (notshown). The serving gNB1 1104 then transmits RRC release message to theUE 1102 with the first NCC value and suspend configuration informationincluding RNA information. After receiving the RRC release message, theUE transitions to the RRC inactive state. When the UE 1102 wants totransmit data in the RRC inactive state, the UE 1102 selects a targetgNB, such as target gNB2 1106, and obtains gNB information, broadcast bythe target gNB2 1106. The UE 1102 may then vertically derive 1302 a newgNB key (K_(gNB2*)) based on the NCC value and the obtained gNBinformation of the target gNB2 1106. The UE 1102 may then transmit datato the target gNB2 1106 using the vertically derived new gNB key(K_(gNB2*)). After the data transmitted by the UE 1102 in the inactivestate is received by target gNB2 1106, the target gNB2 1106 forwards thesecurity information along with target gNB information to the sourcegNB1 1104. The source gNB1 1104 then vertically derives 1212 a new gNBkey (K_(gNB2*)) based on the target gNB information, the first NCCvalue, and NH parameter and transmits the derived new gNB key(K_(gNB2*)) to the target gNB2 1106. When the UE 1102 transmits data inthe RRC inactive state to another target gNB, such as target gNB2 1108,after the initial data transmission, the UE 1102 obtains gNBinformation, broadcast by the target gNB3 1108 and horizontally derives1304 a new gNB key (K_(gNB3*)) based on the previous gNB key, first NCCvalue, and gNB information from the target gNB3 1108. After the datatransmitted by the UE 1102 in the inactive state is received by targetgNB3 1103, the target gNB3 1108 forwards the security information alongwith target gNB information to the source gNB1 1104. The source gNB11104 then horizontally derives a new gNB key (K_(gNB3*)) based on thetarget gNB information, the first NCC value, and NH parameter andtransmits the derived new gNB key (K_(gNB3*)) to the target gNB2 1106.In certain cases, the UE 1102 may want to transition to a connectedstate on a target gNB2 1106 different from the source gNB1 1104. In suchcases, the UE 1102 may perform an RRC resume procedure using theinitially, vertically, derived gNB key (K_(gNB2*)), in a manner similarto that described above in conjunction with FIG. 7 . The UE 1102 mayalso return to the inactive state in a manner similar to that describedabove in conjunction with FIG. 7 .

In certain cases, key generation for inactive state data transmissionsmay be performed using a set of consecutive integer NCC values providedby a source gNB in the RRC release message to generate keys for multiplegNBs. This set of consecutive NCC values may be described by a startingNCC value and an integer, n, indicating how many consecutive NCC valuesare in the set. In these cases, multiple new gNB values may be derivedfrom the set of NCC values included in the RRC release message. Forexample, a source gNB may receive, prior to transmitting an RRC releaseto a UE, a path switch procedure response message including a set of NCCvalues and NH parameters. The set may include any integer number n,where n>1, of consecutive NCC values. The source gNB may then transmitan RRC release message with suspend configuration information includingthe set of NCC values. After the UE enters the RCC inactive state, theUE may want to transmit data in the RCC inactive state. The UE may thenvertically derive a new gNB key based on a first NCC value from the setof NCC values for the first transmission. The UE may continue tovertically a new gNB key based on successive NCC values from the set ofNCC values for each data transmission in the RCC inactive state. After ndata transmissions the UE will have used all of the NCC values from theset of NCC values.

On the network side, data security handling may be provided by multiplealternative handling procedures. In a first alternative network sidedata security handling procedure, the data handling security may beperformed by the source gNB. For example, in this first alternative,when the data transmitted by the UE in the inactive state to a targetgNB, the target gNB forwards the security information of the datatransmitted along with target gNB information to the source gNB. Thesource gNB then returns the gNB key (K_(gNB)) to the target gNB. In asecond alternative network side data security handling procedure, thedata handling security may be performed by each accessed gNB based onNCC/NH pairs broadcast by the source gNB. For example, in this secondalternative, the source gNB, after transmitting the RRC release message,including RNA information, to the UE, may broadcast UE contextinformation including the set of NCC values and NH parameter to theother gNBs in the configured RNA of the UE 802. Then, when the UE 802transmits data to a target gNB, in the inactive state, the target gNBcan derived gNB key (K_(gNB)). In a third alternative network side datasecurity handling procedure, the data handling security may be performedby each accessed gNB based on UE context data retrieved from the sourcegNB. For example, in this third alternative, when the data transmittedby the UE in the inactive state to a target gNB, the target gNB forwardsthe security information of the data transmitted along with target gNBinformation to the source gNB. The source gNB then returns UE contextdata including the NCC value and NH parameter to the target gNB. Thetarget gNB can then derive the gNB key (K_(gNB)).

Additionally, there may be multiple options for handling subsequent datatransmissions after all of the NCC values from the set of NCC values areused. Each of these multiple options may be combined with any of theabove detailed alternative network side data security handlingprocedures.

In a first option, the last gNB key (N_(gNBn*)) derived from the set ofNCC values may be used to horizontally derive subsequent gNB keys(N_(gNBn+m*)) along with gNB information from a target gNB. For example,after all n NCC values in the set of NCC values have been used, the UEmay derive a new gNB key (N_(gNBn+1*)) by using horizontal derivationbased on the currently active (e.g., last) gNB key (N_(gNBn*)) derivedfrom the set of NCC values, along with gNB information of the targetgNB. For each additional data transmission in the RRC inactive state,additional new gNB keys may continue to be generated using horizontalderivation. On the network side, data security may be performed usingany of the above detailed alternative network side data securityhandling procedures.

In a second option, the last gNB key (N_(gNBn*)) derived from the set ofNCC values may be reused for subsequent data transmissions in the RRCinactive state. For example, after all n NCC values in the set of NCCvalues have been used, the UE may continue to use the currently active(e.g., last) gNB key (N_(gNBn*)) derived from the set of NCC values foradditional data transmission in the RRC inactive state. On the networkside, data security may be performed using any of the above detailedalternative network side data security handling procedures.

In a third option, after the NCC values in the set of NCC values havebeen used a RRC resume procedure may be triggered. For example, afterall n NCC values in the set of NCC values have been used, the UE maysend a RRC resume procedure to a target gNB. The NCC value used for theRRC resume procedure may either be the last NCC value in the set of NCCvalues, or there may be a dedicated NCC value for the RCC resumeprocedure provided with the set of NCC values. The target gNB may thentransmit a path switch request to the AMF. The AMF may then respond witha path switch response message including another set of NCC values and aNH parameter. In certain cases, the path switch request procedure mayalso handover the UE from the previous source gNB to the target gNB. Thetarget gNB may then transmit the other set of NCC values to the UE in anRRC release message.

In a fourth option, after the NCC values in the set of NCC values havebeen used, additional new gNB keys (N_(gNBn*)) may be derived in amanner similar to that described in conjunction with the third option1006 of FIG. 10 for deriving additional gNB keys from a single NCCvalue. For example, after all the NCC values in the set of NCC valueshave been used, a new gNB key (K_(gNB)) may be vertically derived basedon the currently active (e.g., last) gNB key (N_(gNBn*)). NCC value, andgNB information. The UE may then reuse the derived new gNB key (K_(gNB))for each subsequent data transmission.

In a fifth option, after the NCC values in the set of NCC values havebeen used, additional new gNB keys (N_(gNBn*)) may be derived in amanner similar to that described in conjunction with the fourth option1008 of FIG. 10 for deriving additional gNB keys from a single NCCvalue. For example, after all the NCC values in the set of NCC valueshave been used, a new gNB key (K_(gNB2*)) may be vertically derivedbased on the currently active (e.g., last) gNB key (N_(gNBn*)), NCCvalue, and obtained gNB information of the target gNB. For subsequentdata transactions, additional new gNB keys (K_(gNBN*)) may also bevertically derived based on the currently active gNB key (e.g.,K_(gNB2*)), NCC value, and obtained gNB information of the target gNB.

In a sixth option, after the NCC values in the set of NCC values havebeen used, additional new gNB keys (N_(gNBn*)) may be derived in amanner similar to that described in conjunction with the sixth option1010 of FIG. 10 for deriving additional gNB keys from a single NCCvalue. For example, after all the NCC values in the set of NCC valueshave been used, a new gNB key (K_(gNB2*)) may be vertically derivedbased on the currently active (e.g., last) gNB key (N_(gNBn*)), NCCvalue and obtained gNB information of the target gNB. For subsequentdata transmissions, additional new gNB keys (K_(gNBN*)) may behorizontally derived based on the currently active gNB key (e.g., gNBkey (K_(gNB2*))).

FIG. 14 is a communications flow diagram illustrating an exampletechnique 1400 for key generation for inactive state data transmissions,in accordance with aspects of the present disclosure. The technique 1400illustrates an example of the third option described above for handlingsubsequent data transmissions after all of the NCC values from the setof NCC values are used in conjunction with the first alternative networkside data security handling procedure. In this example, a source gNB11104 may receive from an AMF 1110, prior to transmitting an RRC releaseto a UE 1102, a path switch procedure response message including a setof NCC values and NH parameter. In this example, the set includes twoconsecutive NCC values and NH parameters (e.g., n=2). The source gNB 11104 may then transmit an RRC release message with suspend configurationinformation including a set of NCC values based on the set of NCC valuesreceived from the AMF 1110. After the UE 1102 enters the RCC inactivestate, the UE 1102 may want to transmit data in the RCC inactive state.The UE 1102 may then vertically derive 1402 a first gNB key (K_(gNB2))based on a first NCC value from the set of NCC values and gNBinformation for a first target gNB2 1106 for a first transmission to thefirst target gNB2 1106, a then forward security information of the firsttransmission along with gNB information to the source gNB1 1104. Thesource gNB1 1104 then vertically derives the first gNB key (K_(gNB2))based on the NCC values and NH parameters received from the AMF and thegNB information received from the first target gNB2 1106 and transmits aresponse back to the first target gNB2 1106 including the first gNB key(K_(gNB2)). As the source gNB1 1102 derives each gNB key, the sourcegNB1 1102 can track NCC value usage and knows which NCC value iscurrently active. When the UE 1102 wants to transmit additional data inthe RRC inactive state, for example, to a second target gNB3 1108, theUE 1102 may vertically derive 1404 a second gNB key (K_(gNB3)) based onthe next (e.g., last) NCC value from the set of NCC values and gNBinformation for the second target gNB3 1108 for a second transmission tothe second target gNB3 1108. The second target gNB3 1108 may obtain thesecond gNB key (K_(gNB3)) in a way similar to the way the first targetgNB2 1106 obtained the first gNB key (K_(gNB2)).

After the second transmission, the UE 1102 may perform an RRC resumeprocedure with, for example, first target gNB2 1106 and transition to anRRC connected mode. In this example, the UE 1102 may use a dedicated NCCvalue included with the set of NCC values to transmit the RRC resumemessage. In other cases, the last NCC value of the set of NCC values maybe used to transmit the RRC resume message. In certain cases, the RRCresume message may include an indication that additional NCC values forsecuring additional data transmissions in the RRC inactive mode areneeded. The first target gNB2 1106 may then transmit a UE context fetchmessage to the source gNB1 1104. The source gNB1 1104 may thenvertically derives the first gNB key (K_(gNB2)) based on NH valuesreceived from the AMF and the gNB information received from the firsttarget gNB2 1106. The first target gNB2 1106 may then transmit a pathswitch request to the AMF 1110. The AMF 1110 may then respond with apath switch response message including another set of NCC values and NHparameter. In certain cases, the path switch request procedure may alsohandover the UE 1102 from the previous source gNB1 1104 to the firsttarget gNB2 1106. The first target gNB2 1106 may then transmit the otherset of NCC values to the UE 1102 in an RRC release message.

FIG. 15 is a communications flow diagram illustrating an exampletechnique 1500 for key generation for inactive state data transmissions,in accordance with aspects of the present disclosure. The technique 1500illustrates an example of the third option described above for handlingsubsequent data transmissions after all of the NCC values from the setof NCC values are used in conjunction with the second alternativenetwork side data security handling procedure. In this example, a sourcegNB1 1104 may receive from an AMF 1110, prior to transmitting an RRCrelease to a UE 1102, a path switch procedure response message includinga set of NCC values and a NH parameter. In this example, the setincludes two NCC values (e.g., n=2). The source gNB1 1104 may thentransmit an RRC release message with suspend configuration informationincluding a set of NCC values based on the NCC values received from theAMF 1110. The source gNB1 1104 may broadcast UE context informationincluding the set of NCC values and NH parameter to the other gNBs(e.g., gNB2 1106 and gNB3 1108) in the configured RNA of the UE 1102.

After the UE 1102 enters the RCC inactive state, the UE 1102 may want totransmit data in the RCC inactive state. The UE 1102 may then verticallyderive 1502 a first gNB key (K_(gNB2)) based on a first NCC value fromthe set of NCC values and gNB information for a first target gNB2 1106for a first transmission to the first target gNB2 1106. After receivingthe first transmission, the first target gNB2 1106 may also verticallyderive the first gNB key (K_(gNB2)) based on the set of NCC values andNH parameter broadcast by the source gNB1 1104. The first target gNB21106 also broadcasts to the other gNBs (e.g., gNB1 1104 and gNB3 1108)in the configured RNA of the UE 1102 a UE data transmission numberindicating which NCC has been used (e.g., an incrementing counter) bythe UE 1102. When the UE 1102 wants to transmit additional data in theRRC inactive state, for example, to a second target gNB3 1108, the UE1102 may vertically derive 1504 a second gNB key (K_(gNB3)) based on thenext (e.g., last) NCC value from the set of NCC values and gNBinformation for the second target gNB3 1108 for a second transmission tothe second target gNB3 1108. The second target gNB3 1108 may similarlyderive the second gNB key (K_(gNB3)) based on the set of NCC valuesbroadcast by the source gNB1 1104. The second target gNB3 1108 alsobroadcasts to the other gNBs (e.g., gNB1 1104 and gNB2 1106) in theconfigured RNA of the UE 1102 another UE data transmission numberindicating which NCC value has been used by the UE 1102.

After the second transmission, the UE 1102 may perform an RRC resumeprocedure in a manner similar to that described above with respect toFIG. 14 . For example, the UE 1102 may use a dedicated NCC valueincluded with the set of NCC values to transmit the RRC resume message.In other cases, the last NCC value of the set of NCC values may be usedto transmit the RRC resume message. In certain cases, the RRC resumemessage may include an indication that additional NCC values forsecuring additional data transmissions in the RRC inactive mode areneeded. The first target gNB2 1106 may then transmit a UE context fetchmessage to the source gNB1 1104. The source gNB1 1104 may thenvertically derives the first gNB key (K_(gNB2)) based on the NHparameter received from the AMF and the gNB information received fromthe first target gNB2 1106. The first target gNB2 1106 may then transmita path switch request to the AMF 1110. The AMF 1110 may then respondwith a path switch response message including another set of NCC valuesand NH parameter. In certain cases, the path switch request proceduremay also handover the UE 1102 from the previous source gNB1 1104 to thefirst target gNB2 1106. The first target gNB2 1106 may then transmit theother set of NCC values to the UE 1102 in an RRC release message.

FIG. 16 is a communications flow diagram illustrating an exampletechnique 1600 for key generation for inactive state data transmissions,in accordance with aspects of the present disclosure. The technique 1600illustrates an example of the third option described above for handlingsubsequent data transmissions after all of the NCC values from the setof NCC values are used in conjunction with the third alternative networkside data security handling procedure. In this example, a source gNB11104 may receive from an AMF 1110, prior to transmitting an RRC releaseto a UE 1102, a path switch procedure response message including a setof NCC values and NH parameter. In this example, the set includes twoNCC values (e.g., n=2). The source gNB1 1104 may then transmit an RRCrelease message with suspend configuration information including a setof two NCC values based on NCC values received from the AMF 1110. Afterthe UE 1102 enters the RCC inactive state, the UE 1102 may want totransmit data in the RCC inactive state. The UE 1102 may then verticallyderive 1602 a first gNB key (K_(gNB2)) based on a first NCC value fromthe et of NCC values and gNB information for a first target gNB2 1106for a first transmission to the first target gNB2 1106. After receivingthe first transmission, the first target gNB2 1106 transmits a UEcontext fetch message to the source gNB1 1104 and the source gNB1 1104responds by returning a UE context response message including the nextNCC value and NH parameter. As a UE context is accessed by the sourcegNB1 1104 each time another gNB receives a data transmission from the UE1102, the source gNB1 1104 can track NCC value usage and knows which NCCvalue is currently active. The first target gNB2 1106 may thenvertically derive the first gNB key (K_(gNB2)) based on the next NCCvalue, NH parameter, and gNB information. When the UE 1102 wants totransmit additional data in the RRC inactive state, for example, to asecond target gNB3 1108, the UE 1102 may vertically derive 1604 a secondgNB key (K_(gNB3)) based on the last NCC value from the set of NCCvalues and gNB information for the second target gNB3 1108 for a secondtransmission to the second target gNB3 1108. The second target gNB3 1108also transmits a UE context fetch message to the source gNB1 1104 andthe source gNB1 1104 responds by returning a UE context response messageincluding the next NCC value and NH parameter. The second target gNB31108 may then vertically derive the first gNB key (K_(gNB2)) based onthe next NCC value, NH parameter, and gNB information. After the secondtransmission, the UE 1102 may perform an RRC resume procedure in amanner similar to that described above with respect to FIG. 14 .

FIG. 17 is a communications flow diagram illustrating an exampletechnique 1700 for key generation for inactive state data transmissions,in accordance with aspects of the present disclosure. The technique 1700illustrates an example using a list of non-consecutive NCC values. Thetechnique 1700 is a variant of using a set of consecutive integer NCCvalues and all options and alternative network side data securityhandling procedure described with respect to the set of consecutiveinteger NCC values may also apply to variants using a list ofnon-consecutive NCC values. For example, the technique 1700 showsoperations with a non-consecutive listing of NCC values used inconjunction with the first alternative network side data securityhandling procedure and omits details regarding handling subsequent datatransmissions after all of the NCC values from the list of NCC valuesare used. It may be understood that all options for handing subsequentdata transmissions after all of the NCC values from the list of NCCvalues and the other alternative network side data security handing andmay also be combined with the non-consecutive listing of NCC values.Instead of describing a set of consecutive NCC values using a startingNCC value and an integer, the set of NCC values may be a non-consecutivelisting of NCC values and NH parameter pairs. Operations using the listof NCC values to derive gNB keys are substantially similar, on both theUE and network side, as described above with respect to the set ofconsecutive NCC values. As compared to operations with the set ofconsecutive NCC values, operations with a non-consecutive listing of NCCvalues would operate with specific NCC values rather than a starting NCCvalue that consecutively increases. For example, in technique 1700, asource gNB1 1104 may receive from an AMF 1110, prior to transmitting anRRC release to a UE 1102, a path switch procedure response messageincluding a list of NCC values and NH parameter pairs (e.g., ((NCC1,NH1), (NCC3, NH3) . . . )). The source gNB1 1104 may then transmit anRRC release message to the UE 1102 with suspend configurationinformation including the list of NCC values. After the UE 1102 entersthe RCC inactive state, the UE 1102 may want to transmit data in the RCCinactive state. The UE 1102 may then vertically derive 1702 a first gNBkey (K_(gNB2)) based on a first NCC value (NCC1) from the set of NCCvalues and gNB information for a first target gNB2 1106 for a firsttransmission to the first target gNB2 1106. After receiving the firsttransmission, the first target gNB2 1106 may then forward securityinformation of the first transmission along with gNB information to thesource gNB11104. The source gNB 1 1104 then vertically derives the firstgNB key (K_(gNB2)) based on NCC values and NH parameters received fromthe AMF and the gNB information received from the first target gNB2 1106and transmits a response back to the first target gNB2 1106 includingthe first gNB key (K_(gNB2)). When the UE 1102 wants to transmitadditional data in the RRC inactive state, for example, to a secondtarget gNB3 1108, the UE 1102 may vertically derive 1704 a second gNBkey (K_(gNB3)) based on the next (e.g., last) NCC value (e.g., NCC3)from the list of NCC values and gNB information for the second targetgNB3 1108 for a second transmission to the second target gNB3 1108. Thesecond target gNB3 1108 may obtain the second gNB key (K_(gNB3)) in away similar to the way the first target gNB2 1106 obtained the first gNBkey (K_(gNB2)).

FIG. 18 is a communications flow diagram illustrating an exampletechnique 1800 for key generation for inactive state data transmissions,in accordance with aspects of the present disclosure. The technique 1800is a variant of other example techniques using a set of consecutiveinteger NCC values whereby the UE includes an indication of which NCCvalue is currently active, such as by using a incrementing counter. Itshould be understood that all options and alternative network side datasecurity handling procedure described with respect to the set ofconsecutive integer NCC values may also apply to technique 1800. Forexample, the technique 1800, as shown, applies the second alternativenetwork side data security handling procedure and omits detailsregarding handling subsequent data transmissions after all of the NCCvalues from the list of NCC values are used. It may be understood thatall options for handing subsequent data transmissions after all of theNCC values from the list of NCC values and the other alternative networkside data security handing and may also be combined with thenon-consecutive listing of NCC values. In this example, a source gNB11104 may receive from an AMF 1110, prior to transmitting an RRC releaseto a UE 1102, a path switch procedure response message including a setof NCC values and a NH parameter. In this example, the set includes twoNCC values (e.g., n=2). The source gNB1 1104 may then transmit an RRCrelease message with suspend configuration information including a setof NCC values based on the NCC values received from the AMF 1110. Thesource gNB1 1104 may broadcast UE context information including the setof NCC values and NH parameters to the other gNBs (e.g., gNB2 1106 andgNB3 1108) in the configured RNA of the UE 1102.

After the UE 1102 enters the RCC inactive state, the UE 1102 may want totransmit data in the RCC inactive state. The UE 1102 may then verticallyderive 1802 a first gNB key (K_(gNB2)) based on a first NCC value fromthe set of NCC values and gNB information for a first target gNB2 1106for a first transmission to the first target gNB2 1106. Included withthe first transmission is a first indication of the current NCC accessnumber. After receiving the first transmission, the first target gNB21106 may also vertically derive the first gNB key (K_(gNB2)) based onthe set of NCC values, the indication of the current NCC access number,and NH parameter broadcast by the source gNB1 1104. When the UE 1102wants to transmit additional data in the RRC inactive state, forexample, to a second target gNB3 1108, the UE 1102 may vertically derive1804 a second gNB key (K_(gNB3)) based on the next (e.g., last) NCCvalue from the set of NCC values and gNB information for the secondtarget gNB3 1108 for a second transmission to the second target gNB31108. Included with the second transmission is a second indication ofthe current NCC access number, the second indication different from thefirst indication (e.g., incremented). The second target gNB3 1108 maysimilarly derive the second gNB key (K_(gNB3)) based on the set of NCCvalues broadcast by the source gNB1 1104 and the second indication ofthe current NCC access number.

FIG. 19 is a communications flow diagram illustrating an exampletechnique 1900 for key generation for inactive state data transmissions,in accordance with aspects of the present disclosure. The technique 1900is an example variant of using a list of non-consecutive NCC valueswhereby the UE includes an indication of which NCC value is currentlyactive, such as by using an incrementing counter. It should beunderstood that all options and alternative network side data securityhandling procedure described with respect to the set of consecutiveinteger NCC values may also apply to technique 1900. For example, thetechnique 1900, as shown, applies the second alternative network sidedata security handling procedure and omits details regarding handlingsubsequent data transmissions after all of the NCC values from the listof NCC values are used. It may be understood that all options forhanding subsequent data transmissions after all of the NCC values fromthe list of NCC values and the other alternative network side datasecurity handing and may also be combined with the non-consecutivelisting of NCC values. For example, in technique 1900, a source gNB11104 may receive from an AMF 1110, prior to transmitting an RRC releaseto a UE 1102, a path switch procedure response message including a listof NCC values and NH parameter pairs (e.g., ((NCC1, NH1), (NCC3, NH3) .. . )). The source gNB1 1104 may then transmit an RRC release message tothe UE 1102 with suspend configuration information including the list ofNCC values. The source gNB1 1104 may broadcast UE context informationincluding the list of NCC values and NH parameters to the other gNBs(e.g., gNB2 1106 and gNB3 1108) in the configured RNA of the UE 1102.

After the UE 1102 enters the RCC inactive state, the UE 1102 may want totransmit data in the RCC inactive state. The UE 1102 may then verticallyderive 1902 a first gNB key (K_(gNB2)) based on a first NCC value (NCC1)from the set of NCC values and gNB information for a first target gNB21106 for a first transmission to the first target gNB2 1106. Includedwith the first transmission is a first indication of the current NCCaccess number. After receiving the first transmission, the first targetgNB2 1106 may also vertically derive the first gNB key (K_(gNB2)) basedon the list of NCC values, the indication of the current NCC accessnumber, and NH parameter broadcast by the source gNB11104. When the UE1102 wants to transmit additional data in the RRC inactive state, forexample, to a second target gNB3 1108, the UE 1102 may vertically derive1904 a second gNB key (K_(gNB3)) based on the next (e.g., last) NCCvalue from the list of NCC values and gNB information for the secondtarget gNB3 1108 for a second transmission to the second target gNB31108. Included with the second transmission is a second indication ofthe current NCC access number, the second indication different from thefirst indication (e.g., incremented). The second target gNB3 1108 maysimilarly derive the second gNB key (K_(gNB3)) based on the list of NCCvalues broadcast by the source gNB1 1104 and the second indication ofthe current NCC access number.

In certain cases, key generation for inactive state data transmissionsmay be performed using a set of NCC values and NH parameters, where theNCC values for a next transmission in an RRC inactive state are providedto a UE. FIG. 20 is a communications flow diagram illustrating anexample technique 2000 for key generation for inactive state datatransmissions, in accordance with aspects of the present disclosure. Thetechnique 2000 illustrates an example of where the NCC values for a nexttransmission in an RRC inactive state are provided to a UE. In thisexample, a source gNB1 1104 may receive, prior to transmitting an RRCrelease to a UE, a path switch procedure response message including aset of NCC values and NH parameters. The set, in a first option, mayinclude multiple NCC values and NH parameters. These multiple NCC valuesand NH parameters may be consecutive NCC values described by a startingNCC value and an integer, n, indicating how many consecutive NCC valuesare in the set, or the set may be a listing of multiple, non-consecutiveNCC values. The set, in a second option, may include a single NCC valueand NH parameter pair. In the second option, each subsequent gNB whichreceives a data transmission from the UE 1102, while in the RRC inactivestate, requests from the CN, such as the AMF 1110, a new NCC value(NCC1) and NH parameter pair for use in the next transmission in the RRCinactive state. In either option, the source gNB1 1104 may then transmitan RRC release message with suspend configuration information includinga first NCC value (NCC1) and RNA information to the UE 1102. The UE 1102may enter the RRC inactive state. The UE 1102 may want to transmit, inthe RRC inactive state, a first transmission to a first target gNB2 1106and may vertically derive 2002 a new first gNB key (K_(gNB2)) based atleast in part on the single NCC value (NCC1) sent to the UE 1102 by thesource gNB1 1104. After receiving the first transmission, the firsttarget gNB2 1106 may perform an alternative network side data securityhandling procedure discussed below. Additionally, the first target gNB21106 may obtain a next second NCC value (NCC2) and NH parameter. Thefirst target gNB2 1106 may provide the next second NCC value (NCC2) tothe UE 1102 by using, for example, a medium access control (MAC) controlelement (MAC-CE), radio link control (RLC) control packet data unit(PDU), or Packet Data Convergence Protocol (PDCP) control PDU signaling.The UE 1102 may further want to transmit, in the RRC inactive state, asecond transmission to a second target gNB3 1108 and may verticallyderive 2004 a new second gNB key (K_(gNB3)) based at least in part onthe next second NCC value (NCC2) sent to the UE 1102 by the first targetgNB2 1106. After receiving the first transmission, the second targetgNB3 1108 may also perform an alternative network side data securityhandling procedure discussed below. Additionally, the second target gNB31108 may obtain a next third NCC value (NCC3) and NH parameter. Thesecond target gNB3 1108 may provide the next third NCC value (NCC3) tothe UE 1102 by using, for example, MAC-CE, RLC control PDU, or PDCPcontrol PDU signaling. The UE 1102 may perform an RRC resume procedurewith, for example, first target gNB2 1106 and transition to an RRCconnected mode. In this example, the UE 1102 may derive 2006 a new thirdgNB key (K_(gNB3*)) based on the third NCC value (NCC3), NH parameter,and/or gNB information for the previously serving gNB3 1108 to transmitthe RRC resume message. The first target gNB2 1106 may then transmit apath switch request to the AMF 1110. The AMF 1110 may then respond witha path switch response message including another set of NCC values andNH parameter. In certain cases, the path switch request procedure mayalso handover the UE 1102. The first target gNB2 1106 may then transmitthe other set of NCC values to the UE 1102 in an RRC release message.

On the network side, in either option, network side data securityhandling may be provided by multiple alternative handling procedures. Ina first alternative, the data handling security may be performed by thesource gNB. This first alternative may be combined with the firstoption. In this first alternative combined with the first option, afterthe first transmission to the first target gNB2 1106 is received, thefirst target gNB2 1106 forwards the security information of the firsttransmission along with first target gNB2 1106 information to the sourcegNB1 1104. The source gNB1 1104 then vertically derives 2002 the newfirst gNB key (K_(gNB2)) based on the set of NCC values and the firsttarget gNB2 1106 information and returns the new first gNB key(K_(gNB2)) to the first target gNB2 1106. Similarly, after a secondtransmission to a second target gNB3 1108 is received, the second targetgNB3 1108 also forwards the security information of the secondtransmission along with second target gNB3 1108 information to thesource gNB1 1104. The source gNB1 1104 may then vertically 2004 derivethe new second gNB key (K_(gNB3)) based on the set of NCC values and thesecond target gNB3 1108 information and returns the new second gNB key(K_(gNB3)) to the second target gNB3 1108.

This first alternative may also be combined with the second option withcertain modifications as compared to the combination with the firstoption. In this combination, the after the first transmission to thefirst target gNB2 1106 is received, the first target gNB2 1106 forwardsthe security information of the first transmission along with firsttarget gNB2 1106 information to the source gNB1 1104. The source gNB11104 then vertically derives 2002 the new first gNB key (K_(gNB2)) basedon the NCC value (NCC1) and the first target gNB2 1106 information andreturns the new first gNB key (K_(gNB2)) to the first target gNB2 1106.The first target gNB2 1106 then connects to the CN, such as the AMF 1110and obtains a next second NCC value (NCC2) and NH parameter. The targetgNB2 1106 then provides the next second NCC value (NCC2) to the UE 1102by using, for example, a MAC-CE, RLC control PDU, or PDCP control PDUsignaling. The target gNB2 1106 may then broadcast an indication to theother gNBs (e.g., gNB1 1104 and gNB3 1108) in the UE's RNA that thetarget gNB2 1106 has the next second NCC value (NCC2). After the secondtransmission to second target gNB3 1108 is received, the second targetgNB3 1108 forwards the security information of the second transmissionalong with second target gNB3 1108 information to the first target gNB21106 based on the broadcasted indication. The first target gNB2 1106 maythen vertically derive 2004 the new second gNB key (K_(gNB3)) based on anow current second NCC value (NCC2), NH parameter received from the CN,and the second target gNB3 1108 information. The first target gNB2 1106then returns the new second gNB key (K_(gNB3)) to the second target gNB31108. The second target gNB3 1108 then obtains a next third NCC value(NCC3) and NH parameter from the CN. The second target gNB3 1108 thenprovides the next third NCC value (NCC3) to the UE 1102 again using, forexample, a MAC-CE, RLC control PDU, or PDCP control PDU signaling. Thesecond target gNB3 1108 may also then broadcast an indication to theother gNBs (e.g., gNB1 1104 and gNB2 1106) in the UE's RNA that thesecond target gNB3 1108 has the next third NCC value (NCC3).

In a second alternative network side data security handling procedure,the data handling security may be performed by each accessed gNB basedon NCC/NH pairs broadcast by the source gNB. This second alternative maybe combined with either the first option or the second option insubstantially the same way. In this second alternative, the source gNB11104 may broadcast UE 1102 context information including the set of NCCvalues (or single NCC value for option 2) and NH parameter to the othergNBs (e.g., gNB2 1106 and gNB2 1108) in the configured RNA of the UE1102. After the UE 1102 enters the RCC inactive state, the UE 1102 maywant to transmit data in the RCC inactive state. The UE 1102 may thenvertically derive 2002 a first gNB key (K_(gNB2)) based on the first NCCvalue (NCC1) received from the source gNB1 1104 and transmit a firsttransmission, in the RRC inactive state, to the first target gNB2 1106.The first target gNB2 1106 may derive the first gNB key (K_(gNB2)) basedon the first NCC value (NCC1) and NH parameter broadcast by the sourcegNB1 1104. The first target gNB2 1106 may also broadcasts to the othergNBs (e.g., gNB1 1104 and gNB3 1108) in the configured RNA of the UE1102 a UE data transmission number indicating which NCC has been used(e.g., an incrementing counter) by the UE 1102. The first target gNB21106 may also obtain a next second NCC value (NCC2) either via the setof NCC values transmitted by the source gNB1 1104 (e.g., for option 1)or connects to the CN, such as the AMF 1110 and obtains the next secondNCC value (NCC2) and NH parameter (e.g., for option 2). The first targetgNB2 1106 then provides the next second NCC value (NCC2) to the UE 1102by using, for example, a MAC-CE, RLC control PDU, or PDCP control PDUsignaling. The first target gNB2 1106 may (e.g., for option 2) broadcastthe NCC value and NH parameter obtained from the CN to the other gNBs(e.g., gNB1 1104 and gNB3 1108) in the configured RNA of the UE 1102. Ifthe UE 1102 wants to transmit more data in the RCC inactive state, theUE 1102 may vertically derive 2004 a second gNB key (K_(gNB2)) based onthe second NCC value (NCC2) received from the first target gNB2 1106 andtransmit a second transmission, in the RRC inactive mode, to secondtarget gNB3 1108. After the second transmission to second target gNB31108 is received from the UE 1102, the second target gNB3 1108 mayvertically derive the second gNB key (K_(gNB2)) based on the second NCCvalue (NCC2) and NH parameter broadcast by the source gNB1 1104 (e.g.,for option 1), or based on the second NCC value (NCC2) and NH parameterbroadcast by the first target gNB2 1106 (e.g., for option 2). The secondtarget gNB3 1108 may also obtain a next third NCC value (NCC3) eithervia the set of NCC values transmitted by the source gNB1 1104 (e.g., foroption 1) or connect to the CN, such as the AMF 1110 and obtain the nextthird NCC value (NCC3) and NH parameter (e.g., for option 2). The secondtarget gNB3 1108 then provides the next second NCC value (NCC2) to theUE 1102 by using, for example, a MAC-CE, RLC control PDU, or PDCPcontrol PDU signaling. The third target gNB3 1108 may (e.g., for option2) broadcast the NCC value and NH parameter obtained from the CN to theother gNBs (e.g., gNB1 1104 and gNB2 1106) in the configured RNA of theUE 1102. The second target gNB3 1108 may also broadcast to the othergNBs (e.g., gNB1 1104 and gNB2 1106) in the configured RNA of the UE1102 another UE data transmission number indicating which NCC value hasbeen used by the UE 1102.

In a third alternative, the data handling security may be performed byeach accessed gNB based on UE context data retrieved from the sourcegNB. This third alternative may be combined with the first option. Inthis third alternative, with the first option, after the datatransmission by the UE 1102 in the inactive state to a first target gNB21106, the first target gNB2 1106 requests UE context data from thesource gNB1 1104. The source gNB1 1104 then returns UE context dataincluding at least the first NCC value (NCC1) and NH parameter to thefirst target gNB2 1106. The first target gNB2 1106 can then verticallyderive 2002 the first gNB key (K_(gNB2)) based on the first NCC value(NCC1) and NH parameter. Similarly, after a second transmission to asecond target gNB3 1108 is received, the second target gNB3 1108 alsorequests UE context data from the source gNB1 1104. The source gNB1 1104then returns UE context data including at least the second NCC value(NCC2) and NH parameter to the second target gNB3 1108. The secondtarget gNB3 1108 can then vertically derive 2004 the second gNB key(K_(gNB3)) based on the second NCC value (NCC2) and NH parameterreceived from the source gNB1 1104.

This third alternative may also be combined with the second option withcertain modifications as compared to the combination with the firstoption. In this combination, the after the first transmission to thetarget gNB2 1106 is received, the target gNB2 1106 requests UE contextdata from the source gNB1 1104. The source gNB 11104 then returns UEcontext data including the first NCC value (NCC1) and NH parameter tothe first target gNB2 1106. The first target gNB2 1106 then connects tothe CN, such as the AMF 1110 and obtains a second NCC value (NCC2) andNH parameter. The target gNB2 1106 then provides the second NCC value(NCC2) to the UE 1102 by using, for example, a MAC-CE, RLC control PDU,or PDCP control PDU signaling. The first target gNB2 1106 may thenbroadcast an indication to the other gNBs (e.g., gNB1 1104 and gNB31108) in the UE's RNA that the first target gNB2 1106 has the nextsecond NCC value (NCC2). After the second transmission to second targetgNB3 1108 is received, the second target gNB3 1108 requests UE contextdata from the first target gNB2 1106 based on the broadcastedindication. The first target gNB2 1106 then returns UE context dataincluding the second NCC value (NCC2) and NH parameter to the secondtarget gNB3 1108. The second target gNB3 1108 may then vertically derive2004 the new second gNB key (K_(gNB3)) based on a now current second NCCvalue (NCC2) and NH parameter received from the first gNB2 1106. Thesecond target gNB3 1108 then obtains a next third NCC value (NCC3) andNH parameter from the CN. The second target gNB3 1108 then provides thenext third NCC value (NCC3) to the UE 1102 again using, for example, aMAC-CE, RLC control PDU, or PDCP control PDU signaling. The secondtarget gNB3 1108 may also then broadcast an indication to the other gNBs(e.g., gNB1 1104 and gNB2 1106) in the UE's RNA that the second targetgNB3 1108 has the next third NCC value (NCC3).

FIG. 21 is a flow diagram illustrating a technique 2100 for keygeneration by a user device for inactive state data transmissions, inaccordance with aspects of the present disclosure. At block 2102 a radioresource control (RRC) suspend message may be received from a firstnode, the RRC suspend message including a next hop (NH) chaining counter(NCC) value. At block 2104, an RRC inactive state may be entered. Atblock 2106, a first node key may be derived based on the first NCCvalue. It may be understood that a node key, as used herein, refers to aderived key that may be used to access a cell, such as a gNB cell, eNBcell, small cell, etc. As examples, the first node key may be based on apreviously used node key, a horizontally derived node key, or avertically derived node key. At block 2108, a first uplink message maybe generated for transmission in the RRC inactive state, based on thefirst node key. At block 2110, the first uplink message may betransmitted to a node while in the RRC inactive state. As may beunderstood, one or more of the various options described with referenceto FIG. 22 may be used in a given wireless communication system atdifferent times and/or according to different settings.

FIG. 22 is a flow diagram illustrating a technique 2200 for generatingadditional keys by the user device for inactive state datatransmissions, in accordance with aspects of the present disclosure. Atblock 2202, a second node key may be derived based on a second NCC valueof multiple NCC values included in the RCC suspend message. As examples,the second node key may be based on a previously used node key, ahorizontally derived node key, or a vertically derived node key. Atblock 2204, a second uplink message may be generated for transmission inthe RRC inactive state based on the second node key. At block 2206, thesecond uplink may be transmitted to a third node while in the RRCinactive state.

FIG. 23 is a flow diagram illustrating a technique 2300 for generatingadditional keys by the user device for inactive state datatransmissions, in accordance with aspects of the present disclosure. Atblock 2302, a second NCC value may be received from the second node. Atblock 2304, a second node key may be derived based on the second NCCvalue. At block 2306, a second uplink message may be generated fortransmission in the RRC inactive state based on the second node key. Atblock 2308, the second uplink message may be transmitted to a third nodewhile in the RRC inactive state.

FIG. 24 is a flow diagram illustrating a technique 2400 for keygeneration by a node for inactive state data transmissions, inaccordance with aspects of the present disclosure. At block 2402, aradio resource control (RRC) suspend message may be sent from a firstnode, to a first user device, the RRC suspend message including a firstnext hop (NH) chaining counter (NCC) value. At block 2204, accessstratum (AS) resources associated with the first user device may bereleased. At block 2206, a first node key may be derived based on thefirst NCC value. As examples, the first node key may be based on apreviously used node key, a horizontally derived node key, or avertically derived node key. At block 2208, a first uplink message fromthe first user device may be received without allocating AS resources tothe first user device. At block 2210, the first uplink message may beunscrambled based on the first NCC value. As may be understood, one ormore of the various options described with reference to FIG. 24 may beused in a given wireless communication system at different times and/oraccording to different settings.

FIG. 25 is a flow diagram illustrating a technique 2500 for generatingadditional keys by node for inactive state data transmissions, inaccordance with aspects of the present disclosure. At block 2502, asecond node key may be derived based on a second NCC value of multipleNCC values, wherein the RCC suspend message includes the multiple NCCvalues. As examples, the second node key may be based on a previouslyused node key, a horizontally derived node key, or a vertically derivednode key. At block 2504, a second uplink message may be received fromthe first user device without allocating AS resources to the first userdevice. At block 2506, the second uplink message may be unscrambledbased on the second node key.

FIG. 26 is a flow diagram illustrating a technique 2600 for generatingadditional keys by node for inactive state data transmissions, inaccordance with aspects of the present disclosure. At block 2602, asecond NCC value may be transmitted form the second node. At block 2604,a second node key may be derived based on the second NCC value. At block2606, a second uplink message may be received from the first user devicewithout allocating AS resources to the first user device. At block 2608,the second uplink message may be unscrambled based on the second nodekey.

It is noted that, while the examples and aspects above focus primarilyon methods to calculate the maximum number of non-overlapping CCEs in acarrier aggregation scenario, similar methodologies and formulae mayalso be applied for calculating the maximum number of PDCCH Candidates(i.e., M) in a wireless communication scenario. Similarly, while theexamples and aspects above focus primarily methods to calculate themaximum number of non-overlapping CCEs in a carrier aggregationscenario, similar methodologies and formulae may also be applied forcalculating limits on the number of blind decodes (BDs) that may beattempted by a UE in a carrier aggregation scenario, as well.

EXAMPLES

In the following sections, further examples are provided.

According to example 1, a method for security key derivation in awireless system is disclosed, comprising: receiving a radio resourcecontrol (RRC) suspend message from a first node, the RRC suspend messageincluding a first next hop (NH) chaining counter (NCC) value; entering aRRC inactive state; deriving a first node key based on the first NCCvalue for use in the RRC inactive state; generating a first uplinkmessage for transmission in the RRC inactive state based on the firstnode key; and transmitting the first uplink message to a node while inthe RRC inactive state.

Example 2 comprises the subject matter of example 1, wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein the first node key is the same as thesecond node key.

Example 3 comprises the subject matter of example 1, wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein deriving the first node key compriseshorizontally deriving the first node key based on the second node key.

Example 4 comprises the subject matter of example 1, wherein the firstNCC value is different from a second NCC value previously used to derivea second node key.

Example 5 comprises the subject matter of example 4, further comprising:receiving first cell information from a second node, wherein the firstnode key is vertically derived based on the first NCC value and thefirst cell information from the second node; generating a second uplinkmessage for transmission in the RRC inactive state based on the firstnode key; and transmitting the second uplink message while in the RRCinactive state.

Example 6 comprises the subject matter of example 4, further comprising:receiving first cell information from a second node, wherein the firstnode key is vertically derived based on the first NCC value and thefirst cell information from the second node; horizontally deriving athird node key based on the first node key; generating a third uplinkmessage for transmission in the RRC inactive state based on the thirdnode key; and transmitting the third uplink message to a node while inthe RRC inactive state.

Example 7 comprises the subject matter of example 5, further comprising:receiving third cell information from a third node; vertically derivinga fourth node key based on the first NCC value and the third cellinformation; generating a third uplink message for transmission in theRRC inactive state based on the fourth node key; and transmitting thethird uplink message while in the RRC inactive state to the third node.

Example 8 comprises the subject matter of example 1, wherein the RRCsuspend message includes multiple NCC values and further comprising:vertically deriving a second node key based on a second NCC value of themultiple NCC values; generating a second uplink message for transmissionin the RRC inactive state based on the second node key; and transmittingthe second uplink message to a node while in the RRC inactive state.

Example 9 comprises the subject matter of example 8, further comprising:determining that each NCC value of the multiple NCC values have beenused to derive a node key; based on the determination that each NCCvalue of the multiple NCC values have been used, horizontally deriving athird node key based on a most recently used previous node key;generating a third uplink message for transmission in the RRC inactivestate based on the third node key; and transmitting the third uplinkmessage to a node while in the RRC inactive state.

Example 10 comprises the subject matter of example 8, furthercomprising: determining that each NCC value of the multiple NCC valueshave been used to derive a node key; generating a third uplink messagefor transmission in the RRC inactive state based on a most recently usedprevious node key; and transmitting the third uplink message to a node w% bile in the RRC inactive state.

Example 11 comprises the subject matter of example 8, furthercomprising: determining that each NCC value of the multiple NCC valueshave been used to derive a node key; and triggering a RRC resumeprocedure.

Example 12 comprises the subject matter of example 1, wherein the firstuplink message is transmitted to a second node and further comprising:receiving a second NCC value from the second node; vertically deriving asecond node key based on the second NCC value; generating a seconduplink message for transmission in the RRC inactive state based on thesecond node key; and transmitting the second uplink message while in theRRC inactive state to a third node.

Example 13 comprises the subject matter of example 1, wherein the firstuplink message is transmitted to a second node and further comprising:receiving a second NCC value from the second node; determining that thesecond NCC value is the same as the first NCC value; horizontallyderiving a second node key based on the first or second NCC value;generating a second uplink message for transmission in the RRC inactivestate based on the second node key; and transmitting the second uplinkmessage while in the RRC inactive state to a third node.

According to example 14, a wireless device is disclosed, comprising: anantenna; a radio operably coupled to the antenna; and a processoroperably coupled to the radio; wherein the wireless device is configuredto: receive a radio resource control (RRC) suspend message from a firstnode, the RRC suspend message including a first next hop (NH) chainingcounter (NCC) value; enter an RRC inactive state; derive a first nodekey based on the first NCC value for use in the RRC inactive state;generate a first uplink message for transmission in the RRC inactivestate based on the first node key; and transmit the first uplink messageto a node while in the RRC inactive state.

Example 15 comprises the subject matter of example 14, wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein the first node key is the same as thesecond node key.

Example 16 comprises the subject matter of example 14, wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein deriving the first node key compriseshorizontally deriving the first node key based on the second node key.

Example 17 comprises the subject matter of example 14, wherein the firstNCC value is different from a second NCC value previously used to derivea second node key.

Example 18 comprises the subject matter of example 17, wherein thewireless device is further configured to: receive first cell informationfrom a second node, wherein the first node key is vertically derivedbased on the first NCC value and the first cell information from thesecond node; generate a second uplink message for transmission in theRRC inactive state based on the first node key, and transmit the seconduplink message while in the RRC inactive state.

Example 19 comprises the subject matter of example 18, wherein thewireless device is further configured to: receive first cell informationfrom the second node, wherein the first node key is vertically derivedbased on the first NCC value and the first cell information from thesecond node; horizontally derive a third node key based on the firstnode key; generate a third uplink message for transmission in the RRCinactive state based on the third node key; and transmit the thirduplink message to a node while in the RRC inactive state.

Example 20 comprises the subject matter of example 18, wherein thewireless device is further configured to: receive third cell informationfrom a third node; vertically derive a fourth node key based on thefirst NCC value and the third cell information; generate a third uplinkmessage for transmission in the RRC inactive state based on the fourthnode key; and transmit the third uplink message while in the RRCinactive state to the third node.

Example 21 comprises the subject matter of example 14, wherein the RRCsuspend message includes multiple NCC values and the wireless device isfurther configured to: vertically derive a second node key based on asecond NCC value of the multiple NCC values; generate a second uplinkmessage for transmission in the RRC inactive state based on the secondnode key; and transmit the second uplink message to a node while in theRRC inactive state.

Example 22 comprises the subject matter of example 21, wherein thewireless device is further configured to: determine that each NCC valueof the multiple NCC values have been used to derive a node key; based onthe determination that each NCC value of the multiple NCC values havebeen used, horizontally derive a third node key based on a most recentlyused previous node key; generate a third uplink message for transmissionin the RRC inactive state based on the third node key; and transmit thethird uplink message to a node while in the RRC inactive state.

Example 23 comprises the subject matter of example 21, wherein thewireless device is further configured to: determine that each NCC valueof the multiple NCC values have been used to derive a node key; generatea third uplink message for transmission in the RRC inactive state basedon a most recently used previous node key; and transmit the third uplinkmessage to a node while in the RRC inactive state.

Example 24 comprises the subject matter of example 21, wherein thewireless device is further configured to: determine that each NCC valueof the multiple NCC values have been used to derive a node key; andtrigger a RRC resume procedure.

Example 25 comprises the subject matter of example 14, wherein the firstuplink message is transmitted to a second node and the wireless deviceis further configured to: receive a second NCC value from the secondnode; vertically derive a second node key based on the second NCC value;generate a second uplink message for transmission in the RRC inactivestate based on the second node key; and transmit the second uplinkmessage while in the RRC inactive state to a third node.

Example 26 comprises the subject matter of example 14, wherein the firstuplink message is transmitted to a second node and the wireless deviceis further configured to: receive a second NCC value from the secondnode; determine that the second NCC value is the same as the first NCCvalue; horizontally derive a second node key based on the first orsecond NCC value; generate a second uplink message for transmission inthe RRC inactive state based on the second node key; and transmit thesecond uplink message while in the RRC inactive state to a third node.

According to example 27, an integrated circuit is disclosed, comprisingcircuitry configured to: cause a wireless device to receive a radioresource control (RRC) suspend message from a first node, the RRCsuspend message including a first next hop (NH) chaining counter (NCC)value; cause a wireless device to enter an RRC inactive state; derive afirst node key based on the first NCC value for use in the RRC inactivestate; generate a first uplink message for transmission in the RRCinactive state based on the first node key; and cause a wireless deviceto transmit the first uplink message to a node while in the RRC inactivestate.

Example 28 comprises the subject matter of example 27, wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein the first node key is the same as thesecond node key.

Example 29 comprises the subject matter of example 27, wherein the firstNCC value is unchanged from a second NCC value previously used to derivea second node key, and wherein deriving the first node key compriseshorizontally deriving the first node key based on the second node key.

Example 30 comprises the subject matter of example 27, wherein the firstNCC value is different from a second NCC value previously used to derivea second node key.

Example 31 comprises the subject matter of example 30, wherein thecircuitry is further configured to: cause the wireless device to receivefirst cell information from a second node, wherein the first node key isvertically derived based on the first NCC value and the first cellinformation from the second node; generate a second uplink message fortransmission in the RRC inactive state based on the first node key; andcause the wireless device to transmit the second uplink message while inthe RRC inactive state.

Example 32 comprises the subject matter of example 31, wherein thecircuitry is further configured to: cause the wireless device to receivefirst cell information from the second node, wherein the first node keyis vertically derived based on the first NCC value and the first cellinformation from the second node; horizontally derive a third node keybased on the first node key; generate a third uplink message fortransmission in the RRC inactive state based on the third node key; andcause the wireless device to transmit the third uplink message to a nodewhile in the RRC inactive state.

Example 33 comprises the subject matter of example 31, wherein thecircuitry is further configured to: cause the wireless device to receivethird cell information from a third node; vertically derive a fourthnode key based on the first NCC value and the third cell information;generate a third uplink message for transmission in the RRC inactivestate based on the fourth node key; and cause the wireless device totransmit the third uplink message while in the RRC inactive state to thethird node.

Example 34 comprises the subject matter of example 27, wherein the RRCsuspend message includes multiple NCC values and wherein the circuitryis further configured to: vertically derive a second node key based on asecond NCC value of the multiple NCC values; generate a second uplinkmessage for transmission in the RRC inactive state based on the secondnode key, and cause the wireless device to transmit the second uplinkmessage to a node while in the RRC inactive state.

Example 35 comprises the subject matter of example 34, wherein thecircuitry is further configured to: determine that each NCC value of themultiple NCC values have been used to derive a node key; based on thedetermination that each NCC value of the multiple NCC values have beenused, horizontally derive a third node key based on a most recently usedprevious node key; generate a third uplink message for transmission inthe RRC inactive state based on the third node key; and cause thewireless device to transmit the third uplink message to a node while inthe RRC inactive state.

Example 36 comprises the subject matter of example 34, wherein thecircuitry is further configured to: determine that each NCC value of themultiple NCC values have been used to derive a node key; generate athird uplink message for transmission in the RRC inactive state based ona most recently used previous node key; and cause the wireless device totransmit the third uplink message to a node while in the RRC inactivestate.

Example 37 comprises the subject matter of example 34, wherein thecircuitry is further configured to: determine that each NCC value of themultiple NCC values have been used to derive a node key; and trigger aRRC resume procedure.

Example 38 comprises the subject matter of example 27, wherein the firstuplink message is transmitted to a second node and wherein the circuitryis further configured to: cause the wireless device to receive a secondNCC value from the second node; vertically derive a second node keybased on the second NCC value; generate a second uplink message fortransmission in the RRC inactive state based on the second node key; andcause the wireless device to transmit the second uplink message while inthe RRC inactive state to a third node.

Example 39 comprises the subject matter of example 27, wherein the firstuplink message is transmitted to a second node and wherein the circuitryis further configured to: cause the wireless device to receive a secondNCC value from the second node; determine that the second NCC value isthe same as the first NCC value; horizontally derive a second node keybased on the first or second NCC value; generate a second uplink messagefor transmission in the RRC inactive state based on the second node key;and cause the wireless device to transmit the second uplink messagewhile in the RRC inactive state to a third node.

According to example 40, a method for security key derivation in awireless system is disclosed, comprising: sending a radio resourcecontrol (RRC) suspend message from a first node, to a first user device,the RRC suspend message including a first next hop (NH) chaining counter(NCC) value; releasing access stratum (AS) resources associated with thefirst user device; deriving a first node key based on the first NCCvalue for use in the RRC inactive state; receiving a first uplinkmessage from the first user device without allocating AS resources tothe first user device; and unscrambling the first uplink message basedon the first NCC value.

Example 41 comprises the subject matter of example 40, wherein the firstuplink message is transmitted to a second node, and wherein the firstnode key is derived by the first node, and further comprising: receivinga request for the first node key by a second node; and transmitting thefirst node key to the second node.

Example 42 comprises the subject matter of example 40, wherein the firstuplink message is transmitted to a second node, and further comprisingtransmitting the first NCC value to the second node, wherein the firstnode key is derived by the second node.

Example 43 comprises the subject matter of example 42, wherein the firstNCC value is transmitted to the second node in response to a request forthe first node key by the second node.

Example 44 comprises the subject matter of example 40-43, wherein thefirst NCC value is unchanged from a second NCC value previously used toderive a second node key, and wherein the first node key is the same asthe second node key.

Example 45 comprises the subject matter of example 40-43, wherein thefirst NCC value is unchanged from a second NCC value previously used toderive a second node key, and wherein deriving the first node keycomprises horizontally deriving the first node key based on the secondnode key.

Example 46 comprises the subject matter of example 40-43, wherein thefirst NCC value is different from a second NCC value previously used toderive a second node key.

Example 47 comprises the subject matter of example 46, furthercomprising: transmitting first cell information from a second node,wherein the first node key is derived based on the first NCC value andthe first cell information from the second node; receiving a seconduplink message from the first user device without allocating ASresources to the first user device; and unscrambling the second uplinkmessage based on the first node key.

Example 48 comprises the subject matter of example 46, furthercomprising: transmitting first cell information from a second node,wherein the first node key is derived based on the first NCC value andthe first cell information from the second node; horizontally deriving athird node key based on the first node key; receiving a third uplinkmessage from the first user device without allocating AS resources tothe first user device; and unscrambling the third uplink message basedon the third node key.

Example 49 comprises the subject matter of example 47, furthercomprising: transmitting third cell information from a third node;deriving a fourth node key based on the first NCC value and the thirdcell information; receiving a third uplink message from the first userdevice without allocating AS resources to the first user device; andunscrambling the third uplink message based on the fourth node key.

Example 50 comprises the subject matter of example 40-43, wherein theRRC suspend message includes multiple NCC values and further comprising:deriving a second node key based on a second NCC value of the multipleNCC values; receiving a second uplink message from the first user devicewithout allocating AS resources to the first user device; andunscrambling the second uplink message based on the second node key.

Example 51 comprises the subject matter of example 50, furthercomprising: determining that each NCC value of the multiple NCC valueshave been used to derive a node key; based on the determination thateach NCC value of the multiple NCC values have been used, horizontallyderiving a third node key based on a most recently used previous nodekey; receiving a third uplink message from the first user device withoutallocating AS resources to the first user device; and unscrambling thesecond uplink message based on the third node key.

Example 52 comprises the subject matter of example 50, furthercomprising: determining that each NCC value of the multiple NCC valueshave been used to derive a node key; receiving a second uplink messagefrom the first user device without allocating AS resources to the firstuser device; and unscrambling the second uplink message based on a mostrecently used previous node key.

Example 53 comprises the subject matter of example 50, furthercomprising: receiving a RRC resume request from the first user deviceafter each NCC value of the multiple NCC values have been used to derivea node key; and transmitting another RRC suspend message that includesanother set of multiple NCC values to the first user device.

Example 54 comprises the subject matter of example 40-43, wherein thefirst uplink message is transmitted to a second node and furthercomprising: transmitting a second NCC value from the second node;deriving a second node key based on the second NCC value; receiving asecond uplink message from the first user device without allocating ASresources to the first user device; and unscrambling the second uplinkmessage based on the second node key.

Example 55 comprises the subject matter of example 40-43, wherein thefirst uplink message is transmitted to a second node and furthercomprising: transmitting the first NCC value from the second node;horizontally deriving a second node key based on the first NCC value;receiving a second uplink message from the first user device withoutallocating AS resources to the first user device; and unscrambling thesecond uplink message based on the second node key.

According to example 56, an apparatus is disclosed, comprising: aprocessor configured to: send a radio resource control (RRC) suspendmessage from the apparatus, to a first user device, the RRC suspendmessage including a first next hop (NH) chaining counter (NCC) value;release access stratum (AS) resources associated with the first userdevice; derive a first node key based on the first NCC value for use inthe RRC inactive state; receive a first uplink message from the firstuser device without allocating AS resources to the first user device;and unscramble the first uplink message based on the first NCC value.

Example 57 comprises the subject matter of example 56, wherein the firstuplink message is transmitted to a second node, and wherein the firstnode key is derived by the apparatus, and wherein the processor isfurther configured to: receiving a request for the first node key by asecond node; and transmitting the first node key to the second node.

Example 58 comprises the subject matter of example 56, wherein the firstuplink message is transmitted to a second node, and wherein theprocessor is further configured to transmit the first NCC value to thesecond node, wherein the first node key is derived by the second node.

Example 59 comprises the subject matter of example 58, wherein the firstNCC value is transmitted to the second node in response to a request forthe first node key by the second node.

Example 60 comprises the subject matter of example 56-59, wherein thefirst NCC value is unchanged from a second NCC value previously used toderive a second node key, and wherein the first node key is the same asthe second node key.

Example 61 comprises the subject matter of example 56-59, wherein thefirst NCC value is unchanged from a second NCC value previously used toderive a second node key, and wherein deriving the first node keycomprises horizontally deriving the first node key based on the secondnode key.

Example 62 comprises the subject matter of example 56-59, wherein thefirst NCC value is different from a second NCC value previously used toderive a second node key.

Example 63 comprises the subject matter of example 62, wherein theprocessor is further configured to: transmit first cell information froma second node, wherein the first node key is derived based on the firstNCC value and the first cell information from the second node; receive asecond uplink message from the first user device without allocating ASresources to the first user device, and unscramble the second uplinkmessage based on the first node key.

Example 64 comprises the subject matter of example 62, wherein theprocessor is further configured to: transmit first cell information fromthe first node, wherein the first node key is derived based on the firstNCC value and the first cell information from the first node,horizontally derive a third node key based on the first node key;receive a third uplink message from the first user device withoutallocating AS resources to the first user device; and unscramble thethird uplink message based on the third node key.

Example 65 comprises the subject matter of example 64, wherein theprocessor is further configured to: transmit third cell information froma third node; derive a fourth node key based on the first NCC value andthe third cell information; receive a third uplink message from thefirst user device without allocating AS resources to the first userdevice; and unscramble the third uplink message based on the fourth nodekey.

Example 66 comprises the subject matter of example 56-59, wherein theRRC suspend message includes multiple NCC values and the processor isfurther configured to: derive a second node key based on a second NCCvalue of the multiple NCC values; receive a second uplink message fromthe first user device without allocating AS resources to the first userdevice; and unscramble the second uplink message based on the secondnode key.

Example 67 comprises the subject matter of example 66, wherein theprocessor is further configured to: determine that each NCC value of themultiple NCC values have been used to derive a node key; based on thedetermination that each NCC value of the multiple NCC values have beenused, horizontally derive a third node key based on a most recently usedprevious node key; receive a third uplink message from the first userdevice without allocating AS resources to the first user device; andunscramble the second uplink message based on the third node key.

Example 68 comprises the subject matter of example 66, wherein theprocessor is further configured to: determine that each NCC value of themultiple NCC values have been used to derive a node key; receive asecond uplink message from the first user device without allocating ASresources to the first user device; and unscramble the second uplinkmessage based on a most recently used previous node key.

Example 69 comprises the subject matter of example 66, wherein theprocessor is further configured to: receive a RRC resume request fromthe first user device after each NCC value of the multiple NCC valueshave been used to derive a node key; and transmit another RRC suspendmessage that includes another set of multiple NCC values to the firstuser device.

Example 70 comprises the subject matter of example 56-59, wherein thefirst uplink message is transmitted to a second node and the processoris further configured to: transmit a second NCC value from the secondnode; derive a second node key based on the second NCC value; receive asecond uplink message from the first user device without allocating ASresources to the first user device; and unscramble the second uplinkmessage based on the second node key.

Example 71 comprises the subject matter of example 56-59, wherein thefirst uplink message is transmitted to a second node and the processoris further configured to: transmit the first NCC value from the secondnode; horizontally derive a second node key based on the first NCCvalue; receive a second uplink message from the first user devicewithout allocating AS resources to the first user device; and unscramblethe second uplink message based on the second node key.

Yet another exemplary example may include a method, comprising, by adevice, performing any or all parts of the preceding Examples.

A yet further exemplary example may include a non-transitorycomputer-accessible memory medium comprising program instructions which,when executed at a device, cause the device to implement any or allparts of any of the preceding Examples.

A still further exemplary example may include a computer programcomprising instructions for performing any or all parts of any of thepreceding Examples.

Yet another exemplary example may include an apparatus comprising meansfor performing any or all of the elements of any of the precedingExamples.

Still another exemplary example may include an apparatus comprising aprocessor configured to cause a device to perform any or all of theelements of any of the preceding Examples.

It is well understood that the use of personally identifiableinformation should follow privacy policies and practices that aregenerally recognized as meeting or exceeding industry or governmentalrequirements for maintaining the privacy of users. In particular,personally identifiable information data should be managed and handledso as to minimize risks of unintentional or unauthorized access or use,and the nature of authorized use should be clearly indicated to users.

Aspects of the present disclosure may be realized in any of variousforms. For example, some aspects may be realized as acomputer-implemented method, a computer-readable memory medium, or acomputer system. Other aspects may be realized using one or morecustom-designed hardware devices such as ASICs. Still other aspects maybe realized using one or more programmable hardware elements such asFPGAs.

In some aspects, a non-transitory computer-readable memory medium may beconfigured so that it stores program instructions and/or data, where theprogram instructions, if executed by a computer system, cause thecomputer system to perform a method, e.g., any of a method examplesdescribed herein, or, any combination of the method examples describedherein, or, any subset of any of the method examples described herein,or, any combination of such subsets.

In some examples, a device (e.g., a UE 106, a BS 102, a network element600) may be configured to include a processor (or a set of processors)and a memory medium, where the memory medium stores programinstructions, where the processor is configured to read and execute theprogram instructions from the memory medium, where the programinstructions are executable to implement any of the various methodexamples described herein (or, any combination of the method examplesdescribed herein, or, any subset of any of the method examples describedherein, or, any combination of such subsets). The device may be realizedin any of various forms.

Although the examples above have been described in considerable detail,numerous variations and modifications will become apparent to thoseskilled in the art once the above disclosure is fully appreciated. It isintended that the following claims be interpreted to embrace all suchvariations and modifications.

1. A method for security key derivation in a wireless system,comprising: receiving a radio resource control (RRC) suspend messagefrom a first node, the RRC suspend message including a first next hop(NH) chaining counter (NCC) value; entering a RRC inactive state;deriving a first node key based on the first NCC value for use in theRRC inactive state; generating a first uplink message for transmissionin the RRC inactive state based on the first node key; and transmittingthe first uplink message to a node while in the RRC inactive state. 2.The method of claim 1, wherein the first NCC value is unchanged from asecond NCC value previously used to derive a second node key, andwherein the first node key is the same as the second node key.
 3. Themethod of claim 1, wherein the first NCC value is unchanged from asecond NCC value previously used to derive a second node key, andwherein deriving the first node key comprises horizontally deriving thefirst node key based on the second node key.
 4. The method of claim 1,wherein the first NCC value is different from a second NCC valuepreviously used to derive a second node key.
 5. The method of claim 4,further comprising: receiving first cell information from a second node,wherein the first node key is vertically derived based on the first NCCvalue and the first cell information from the second node; generating asecond uplink message for transmission in the RRC inactive state basedon the first node key; and transmitting the second uplink message whilein the RRC inactive state.
 6. The method of claim 4, further comprising:receiving first cell information from a second node, wherein the firstnode key is vertically derived based on the first NCC value and thefirst cell information from the second node; horizontally deriving athird node key based on the first node key; generating a third uplinkmessage for transmission in the RRC inactive state based on the thirdnode key; and transmitting the third uplink message to a node while inthe RRC inactive state.
 7. The method of claim 5, further comprising:receiving third cell information from a third node; vertically derivinga fourth node key based on the first NCC value and the third cellinformation; generating a third uplink message for transmission in theRRC inactive state based on the fourth node key; and transmitting thethird uplink message while in the RRC inactive state to the third node.8. The method of claim 1, wherein the RRC suspend message includesmultiple NCC values and further comprising: vertically deriving a secondnode key based on a second NCC value of the multiple NCC values;generating a second uplink message for transmission in the RRC inactivestate based on the second node key; and transmitting the second uplinkmessage to a node while in the RRC inactive state.
 9. (canceled)
 10. Themethod of claim 8, further comprising: determining that each NCC valueof the multiple NCC values have been used to derive a node key;generating a third uplink message for transmission in the RRC inactivestate based on a most recently used previous node key; and transmittingthe third uplink message to a node while in the RRC inactive state. 11.The method of claim 8, further comprising: determining that each NCCvalue of the multiple NCC values have been used to derive a node key;and triggering a RRC resume procedure.
 12. The method of claim 1,wherein the first uplink message is transmitted to a second node andfurther comprising: receiving a second NCC value from the second node;vertically deriving a second node key based on the second NCC value;generating a second uplink message for transmission in the RRC inactivestate based on the second node key; and transmitting the second uplinkmessage while in the RRC inactive state to a third node.
 13. (canceled)14. A wireless device comprising: an antenna; a radio operably coupledto the antenna; and a processor operably coupled to the radio; whereinthe wireless device is configured to: receive a radio resource control(RRC) suspend message from a first node, the RRC suspend messageincluding a first next hop (NH) chaining counter (NCC) value; enter anRRC inactive state; derive a first node key based on the first NCC valuefor use in the RRC inactive state; generate a first uplink message fortransmission in the RRC inactive state based on the first node key; andtransmit the first uplink message to a node while in the RRC inactivestate.
 15. The wireless device of claim 14, wherein the first NCC valueis unchanged from a second NCC value previously used to derive a secondnode key, and wherein the first node key is the same as the second nodekey.
 16. The wireless device of claim 14, wherein the first NCC value isunchanged from a second NCC value previously used to derive a secondnode key, and wherein deriving the first node key comprises horizontallyderiving the first node key based on the second node key.
 17. Thewireless device of claim 14, wherein the first NCC value is differentfrom a second NCC value previously used to derive a second node key. 18.The wireless device of claim 17, wherein the wireless device is furtherconfigured to: receive first cell information from a second node,wherein the first node key is vertically derived based on the first NCCvalue and the first cell information from the second node; generate asecond uplink message for transmission in the RRC inactive state basedon the first node key; and transmit the second uplink message while inthe RRC inactive state.
 19. The wireless device of claim 18, wherein thewireless device is further configured to: receive first cell informationfrom the second node, wherein the first node key is vertically derivedbased on the first NCC value and the first cell information from thesecond node; horizontally derive a third node key based on the firstnode key; generate a third uplink message for transmission in the RRCinactive state based on the third node key; and transmit the thirduplink message to a node while in the RRC inactive state.
 20. Thewireless device of claim 18, wherein the wireless device is furtherconfigured to: receive third cell information from a third node;vertically derive a fourth node key based on the first NCC value and thethird cell information; generate a third uplink message for transmissionin the RRC inactive state based on the fourth node key; and transmit thethird uplink message while in the RRC inactive state to the third node.21-30. (canceled)
 31. An integrated circuit, comprising circuitryconfigured to: cause a wireless device to receive a radio resourcecontrol (RRC) suspend message from a first node, the RRC suspend messageincluding a first next hop (NH) chaining counter (NCC) value; cause awireless device to enter an RRC inactive state; derive a first node keybased on the first NCC value for use in the RRC inactive state; generatea first uplink message for transmission in the RRC inactive state basedon the first node key; and cause a wireless device to transmit the firstuplink message to a node while in the RRC inactive state.
 32. Theintegrated circuit of claim 31, wherein the first NCC value is unchangedfrom a second NCC value previously used to derive a second node key, andwherein the first node key is the same as the second node key. 33-44.(canceled)